Hello guys,
this is for those of you how is wondering in which direction development of x2gokdrive is going. As you may know, I mostly working now on the development of x2go kdrive, which will be used parallel to NX. The client part of x2go kdrive is quite simple and not depends on Xorg, which makes possible to create the clients for mobile and web platforms. I made some proof of concept and quickly developed a simple HTML5 client which is connecting to x2gokdrive over websockets. I used websockify to connect ws to tcp socket. The client has limited support for mouse and keyboard events, no support for cursors, but it's enough to create the image how it'll work. I attached the screenshot of plasma5 session running in browser tab with libreoffice and youtube video running in browser.
regards, Alex
Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461
Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder
Amtsgericht München | http://www.phoca-gmbh.de HRB 196 658 | http://www.x2go.org USt-IdNr.: DE281977973
Hi Alex,
Am 06.05.20 um 19:57 schrieb Oleksandr Shneyder:
As you may know, I mostly working now on the development of x2go kdrive, which will be used parallel to NX. The client part of x2go kdrive is quite simple and not depends on Xorg, which makes possible to create the clients for mobile and web platforms. I made some proof of concept and quickly developed a simple HTML5 client which is connecting to x2gokdrive over websockets. I used websockify to connect ws to tcp socket. The client has limited support for mouse and keyboard events, no support for cursors, but it's enough to create the image how it'll work. I attached the screenshot of plasma5 session running in browser tab with libreoffice and youtube video running in browser.
This sure looks interesting - but I do wonder, why the kdrive-only approach, when we've been discussing/working on an HTML5 client for X2Go since the last gathering?
Sounds like unneccessarily doubling the work/reinventing the wheel, and this for a partial solution only. *headscratch*
-Stefan
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
With x2gokdrive you only have to deal with images while with bx you have to implement a X server in the browser.
Uli
Stefan Baur <X2Go-ML-1@baur-itcs.de> schrieb am Do., 7. Mai 2020, 08:44:
Hi Alex,
Am 06.05.20 um 19:57 schrieb Oleksandr Shneyder:
As you may know, I mostly working now on the development of x2go kdrive, which will be used parallel to NX. The client part of x2go kdrive is quite simple and not depends on Xorg, which makes possible to create the clients for mobile and web platforms. I made some proof of concept and quickly developed a simple HTML5 client which is connecting to x2gokdrive over websockets. I used websockify to connect ws to tcp socket. The client has limited support for mouse and keyboard events, no support for cursors, but it's enough to create the image how it'll work. I attached the screenshot of plasma5 session running in browser tab with libreoffice and youtube video running in browser.
This sure looks interesting - but I do wonder, why the kdrive-only approach, when we've been discussing/working on an HTML5 client for X2Go since the last gathering?
Sounds like unneccessarily doubling the work/reinventing the wheel, and this for a partial solution only. *headscratch*
-Stefan
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
x2go-user mailing list x2go-user@lists.x2go.org https://lists.x2go.org/listinfo/x2go-user
Am 07.05.20 um 09:01 schrieb Ulrich Sibiller:
With x2gokdrive you only have to deal with images while with bx you have to implement a X server in the browser.
Obviously. But I thought Mike#1 specified a particular framework he wanted to use, and this one doesn't sound like it's the same. At least the name doesn't ring any bells. So, two different frameworks that we'll have to stitch together somehow if we want a unified HTML5 client for NX and KDrive - or we'll have to ditch whatever Alex' did and start from scratch to get KDrive integrated into Mike#1's approach ... both options seem less than ideal.
-Stefan
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
Hi Stefan hi Alex, hi Uli,
On Do 07 Mai 2020 09:28:50 CEST, Stefan Baur wrote:
Am 07.05.20 um 09:01 schrieb Ulrich Sibiller:
With x2gokdrive you only have to deal with images while with bx you have to implement a X server in the browser.
Obviously. But I thought Mike#1 specified a particular framework he wanted to use, and this one doesn't sound like it's the same. At least the name doesn't ring any bells. So, two different frameworks that we'll have to stitch together somehow if we want a unified HTML5 client for NX and KDrive - or we'll have to ditch whatever Alex' did and start from scratch to get KDrive integrated into Mike#1's approach ... both options seem less than ideal.
-Stefan
The work Alex is doing is exactly what I discussed with him. My
approach of providing X2Go through VNC in a web platform would only
have been an interim solution.
I am still planning to work on a X2Go Session Broker based frontend
for X2Go and will happily use Alex html5 client code (instead of
NoVNC) in it.
This sounds all pretty much promising! Mike
DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
Am 07.05.20 um 10:14 schrieb Mike Gabriel:
The work Alex is doing is exactly what I discussed with him. My approach of providing X2Go through VNC in a web platform would only have been an interim solution.
Alright, that's good to know! :)
I am still planning to work on a X2Go Session Broker based frontend for X2Go and will happily use Alex html5 client code (instead of NoVNC) in it.
Okay, now you've got me confused: What does an X2Go Session Broker have to do with the NX HTML5 client? I mean, obviously, that would be a nice add-on, but we should have a foundation before discussing bells and whistles for the interior design of the house we're building.
-Stefan
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
Hi Stefan,
On Do 07 Mai 2020 10:29:13 CEST, Stefan Baur wrote:
Am 07.05.20 um 10:14 schrieb Mike Gabriel:
The work Alex is doing is exactly what I discussed with him. My approach of providing X2Go through VNC in a web platform would only have been an interim solution.
Alright, that's good to know! :)
:-)
I am still planning to work on a X2Go Session Broker based frontend for X2Go and will happily use Alex html5 client code (instead of NoVNC) in it.
Okay, now you've got me confused: What does an X2Go Session Broker have to do with the NX HTML5 client? I mean, obviously, that would be a nice add-on, but we should have a foundation before discussing bells and whistles for the interior design of the house we're building.
The broker will handle the server-side(!!!) storing and provisioning
of session profiles and dispatch session possibly to other servers
(webserver being exposed in the DMZ, while X2Go Servers are on the
intranet, just to pick one use case).
Mike
DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
Am 07.05.20 um 10:35 schrieb Mike Gabriel:
Okay, now you've got me confused: What does an X2Go Session Broker have to do with the NX HTML5 client? I mean, obviously, that would be a nice add-on, but we should have a foundation before discussing bells and whistles for the interior design of the house we're building.
The broker will handle the server-side(!!!) storing and provisioning of session profiles and dispatch session possibly to other servers (webserver being exposed in the DMZ, while X2Go Servers are on the intranet, just to pick one use case).
Again, that sounds nice as an add-on, but basic NX support in an HTML5 client should take priority. After all, that's what our sponsors asked for - and not a broker-/multi-server DMZ solution. It's fine to design the solution with a possible broker-add-on in mind, but please don't focus on the broker more than on the NX support.
-Stefan
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
Hi Stefan,
On Do 07 Mai 2020 10:38:11 CEST, Stefan Baur wrote:
Am 07.05.20 um 10:35 schrieb Mike Gabriel:
Again, that sounds nice as an add-on, but basic NX support in an HTML5 client should take priority. After all, that's what our sponsors asked for - and not a broker-/multi-server DMZ solution. It's fine to design the solution with a possible broker-add-on in mind, but please don't focus on the broker more than on the NX support.
Why stick to the NX support, if we have a native graphical backend
that's html5 compliant.
The NX -> x11vnc -> NoVNC solution will always be worse (slower, more
itchy and glitchy).
(and: it should not be a big deal to implement it once we have the web
framework around it).
Mike
DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
Am 07.05.20 um 10:48 schrieb Mike Gabriel:
Again, that sounds nice as an add-on, but basic NX support in an HTML5 client should take priority. After all, that's what our sponsors asked for - and not a broker-/multi-server DMZ solution. It's fine to design the solution with a possible broker-add-on in mind, but please don't focus on the broker more than on the NX support.
Why stick to the NX support, if we have a native graphical backend that's html5 compliant.
Again: Because classic X2Go HTML5 support is what the sponsor wants to see. KDrive, Broker, Sound, Printer- and Filesharing - nice bells and whistles, but not what the sponsor wants.
NX is stable, NX is what they're used to, so they ask for it to be used. We're way past the stage where we could negotiate "Can't we just use KDrive instead of NX?".
I would also like to remind you that I don't consider KDrive production-ready for general use yet. It may work for Alex' customers, but last time I tried, I still saw quite a few quirks due to the session not recognizing that it is a remote session (showing popups that only make sense for a local user, granting permissions that a remote user should not have, etc.).
Those are blockers for a stable release and from my understanding, they need to be fixed in the Desktop Environments, not on the X2Go/KDrive side. And such changes are unlikely to get introduced/back-ported to already-existing long term releases of Linux distributions - which most sponsors/commercial users of X2Go are using.
So I doubt we'll see KDrive support becoming generally available until the next major releases of the most popular long-term distros. And that's not how long a sponsor should have to wait for a sponsored feature. Plus it might have a negative impact on their willingness to fund further work.
In a Pre-Corona world, I would have said I'd like to see results before or at the next Gathering. But if we get hit with another infection wave, who knows when the next Gathering will be, so that's not really an "anchor" for a time frame I would like to use right now. ;-)
The NX -> x11vnc -> NoVNC solution will always be worse (slower, more itchy and glitchy).
Maybe you could grab the NX output while still on the host (like, running a fake X2GoClient directly on the server), then push the output towards the HTML5 client the same way Alex' KDrive-HTML5 solution does? That could work as some kind of compatibility layer. That way, the DE would recognize a remote session (even though it's actually connected through 127.0.0.1 or ::1), so we don't have to deal with the quirks/wait for the fixes, yet you'd still only need one backend to talk to the HTML5 client, not two.
-Stefan
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
On Do 07 Mai 2020 11:15:38 CEST, Stefan Baur wrote:
Maybe you could grab the NX output while still on the host (like, running a fake X2GoClient directly on the server), then push the output towards the HTML5 client the same way Alex' KDrive-HTML5 solution does? That could work as some kind of compatibility layer. That way, the DE would recognize a remote session (even though it's actually connected through 127.0.0.1 or ::1), so we don't have to deal with the quirks/wait for the fixes, yet you'd still only need one backend to talk to the HTML5 client, not two.
Hmmm, this would also be a nested solution. I'll check which one is faster.
Mike
DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
Am 07.05.20 um 11:21 schrieb Mike Gabriel:
Maybe you could grab the NX output while still on the host (like, running a fake X2GoClient directly on the server), then push the output towards the HTML5 client the same way Alex' KDrive-HTML5 solution does? That could work as some kind of compatibility layer. That way, the DE would recognize a remote session (even though it's actually connected through 127.0.0.1 or ::1), so we don't have to deal with the quirks/wait for the fixes, yet you'd still only need one backend to talk to the HTML5 client, not two.
Hmmm, this would also be a nested solution. I'll check which one is faster.
The thing is:
- It would satisfy the sponsor's requirement for NX support
- It uses the same Server-Client protocol as Alex' solution
- It is available now, without having to wait for the DEs to adapt
The NX->novnc approach may cover conditon 1), but not condition 2), so, extra effort is needed to make it work. Using KDrive only breaks condition 1) and 3).
Fantasizing a bit here:
When using "NX compatibility mode" in KDrive-HTML5, it would merely have to start a session that only consists of X2GoClient in hidden mode (or pyhoca-cli) with a session to localhost, passing through the credentials provided via the HTML5 client. Maybe add OpenBox or some other minimalistic window manager, but no full DE. So no annoying popups from a DE that believes it's handling a local session.
This is not about speed. This may not even be a long-term solution - once KDrive works with all major distros/DEs, it may even be something we can drop again. But for now, it would cover all three conditions listed above, in a timeframe that doesn't sound like it would have to be that far in the future as full major distro/DE support.
-Stefan
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
On Thu, May 7, 2020 at 11:15 AM Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
NX is stable, NX is what they're used to, so they ask for it to be used. We're way past the stage where we could negotiate "Can't we just use KDrive instead of NX?".
The question is: what's the key point that makes them love NX?
I would also like to remind you that I don't consider KDrive production-ready for general use yet. It may work for Alex' customers, but last time I tried, I still saw quite a few quirks due to the session not recognizing that it is a remote session (showing popups that only make sense for a local user, granting permissions that a remote user should not have, etc.).
Well, KDrive is working as a replacement for x2goagent. And both are working as an X server. The session setup should be the same (x2go scripts). So from the OS view there's no difference. So I don't really understand the points you made above. They are probably not tied to KDrive but some other configuration issue and should happen the same for x2goagent on the same system.
So I doubt we'll see KDrive support becoming generally available until the next major releases of the most popular long-term distros. And that's not how long a sponsor should have to wait for a sponsored feature. Plus it might have a negative impact on their willingness to fund further work.
In a Pre-Corona world, I would have said I'd like to see results before or at the next Gathering. But if we get hit with another infection wave, who knows when the next Gathering will be, so that's not really an "anchor" for a time frame I would like to use right now. ;-)
Which might even boost the whole thing because people tend to have more time. Unfortunately that's not valid for me... ;-(
Maybe you could grab the NX output while still on the host (like, running a fake X2GoClient directly on the server), then push the output towards the HTML5 client the same way Alex' KDrive-HTML5 solution does? That could work as some kind of compatibility layer. That way, the DE
As I wrote before: this makes NX absolutely obsolete. You can then just use kdrive and be fine.
Uli
Hi Uli,
On Do 07 Mai 2020 11:29:41 CEST, Ulrich Sibiller wrote:
As I wrote before: this makes NX absolutely obsolete. You can then just use kdrive and be fine.
NX has its performance advantage on WAN connections when used with
appropriate desktops. That's why I think we should keep both
technologies around, until everything else has become Wayland anyway
(20 years+).
The charming side about the image/compression protocol behind X2Go
Kdrive is that it is X11 agnostic and can plugged into Wayland
compositors, as well. No changes required on the client-side at all
for this.
Mike
DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
Am 07.05.20 um 11:29 schrieb Ulrich Sibiller:
[...]
Well, KDrive is working as a replacement for x2goagent. And both are working as an X server. The session setup should be the same (x2go scripts). So from the OS view there's no difference. So I don't really understand the points you made above. They are probably not tied to KDrive but some other configuration issue and should happen the same for x2goagent on the same system.
[...]
Maybe you could grab the NX output while still on the host (like, running a fake X2GoClient directly on the server), then push the output towards the HTML5 client the same way Alex' KDrive-HTML5 solution does? That could work as some kind of compatibility layer. That way, the DE
As I wrote before: this makes NX absolutely obsolete. You can then just use kdrive and be fine.
And this is where you are mistaken.
For some reason, KDrive sessions are detected as local sessions. So users are allowed to click "shut down the server" - and it will actually happen. On the other hand, they are getting popups about Network connections that ask for sudo permissions to continue and whatnot.
A plain, classic-NX X2Go session on the same server works just fine.
$SOMETHING inside the DE is trying to tell local and remote sessions apart (which is a good thing), and KDrive is confusing this detection mechanism due to how it works, so you get all those weird effects (which is a bad thing).
-Stefan
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
On Thu, May 7, 2020 at 11:42 AM Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
For some reason, KDrive sessions are detected as local sessions. So users are allowed to click "shut down the server" - and it will actually happen. On the other hand, they are getting popups about Network connections that ask for sudo permissions to continue and whatnot.
Well, if this is the only showstopper the admin can still disable that in the DE configuration.
A plain, classic-NX X2Go session on the same server works just fine.
$SOMETHING inside the DE is trying to tell local and remote sessions apart (which is a good thing), and KDrive is confusing this detection mechanism due to how it works, so you get all those weird effects (which is a bad thing).
I guess this also happens with Xephyr then but not with Xnest.
Uli
Am 07.05.20 um 11:51 schrieb Ulrich Sibiller:
A plain, classic-NX X2Go session on the same server works just fine.
$SOMETHING inside the DE is trying to tell local and remote sessions apart (which is a good thing), and KDrive is confusing this detection mechanism due to how it works, so you get all those weird effects (which is a bad thing). I guess this also happens with Xephyr then but not with Xnest.
That guess goes into the right direction, I'd say. Just a few days ago I ran OpenBox on :1 inside Xephyr, and made the mistake of clicking "exit" there. Zap, my actual session on :0 went down as well.
-Stefan
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
On Thu, May 7, 2020 at 12:00 PM Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
I guess this also happens with Xephyr then but not with Xnest.
That guess goes into the right direction, I'd say. Just a few days ago I ran OpenBox on :1 inside Xephyr, and made the mistake of clicking "exit" there. Zap, my actual session on :0 went down as well.
Is probably related to dbus. You need to unset the dbus environment beforehand.
Uli
On Do 07 Mai 2020 11:59:57 CEST, Stefan Baur wrote:
Am 07.05.20 um 11:51 schrieb Ulrich Sibiller:
A plain, classic-NX X2Go session on the same server works just fine.
$SOMETHING inside the DE is trying to tell local and remote sessions apart (which is a good thing), and KDrive is confusing this detection mechanism due to how it works, so you get all those weird effects (which is a bad thing). I guess this also happens with Xephyr then but not with Xnest.
That guess goes into the right direction, I'd say. Just a few days ago I ran OpenBox on :1 inside Xephyr, and made the mistake of clicking "exit" there. Zap, my actual session on :0 went down as well.
-Stefan
You need to wrap openboard into a "dbus-run-session", e.g.
one shell:
Xephyr -ac :1
other shell:
STARTUP=openbox-session dbus-run-session /etc/X11/Xsession
This is another cup of tea and related to systemd's Dbus integration
concept (1 user <-> 1 session, even if on multiple seats)
Mike
DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
Hello guys,
Looks like my E-Mail brought some excitement into the list :) First of all it was not my intention, I just wanted to share with you some of my thoughts. Second, I don't think that we will have something ready before the end of the year (depending on the resources I'll have). For sure, if some one wants to work into the same direction, you are welcome. I also want to add some of my thoughts about NX and X2Go. NX is obsolete. It was obsolete many years ago. Xorg is becoming obsolete as well. And X2Go is already obsolete too, because we are sticking to this technologies way too long. Don't understand me wrong, those are great technologies, which will be used for many years more by some people and companies, we should not drop their support and we should not stop to improve them. But we also should not things like NX slow down our development. Because majority of the users don't want NX. They want to use modern desktops and modern applications. And they don't care, that NX works better with legacy desktops and legacy X11 apps on 256K network, because they are not using them anyway and they have at home in worse case 10M network and even on their cell phones they have a good Internet connection.
@Stefan: I think it's great, that you finding sponsoring and it helps to support the project. But we also should not forget, to separate the wishes of our sponsors and our customers from that what is good for the project. We can't concentrate only on that what our sponsors want, because in this case at some point they'll be our only users. We should also think more about future and what should we do to win new users to the project.
At the end I want to give you some points I think I will work on in the next one or two years:
- Improvement of x2go kdrive: adaptive compression level, video compression for some regions, frame dropping, etc
- x2gokdrive client - HTML5, Using OpenGL for image composition
- Finally rewrite x2go client, multi session support, x2go kdrive client should be part of x2go client, etc.
regards, Alex
Am 07.05.20 um 04:15 schrieb Stefan Baur:
Am 07.05.20 um 10:48 schrieb Mike Gabriel:
Again, that sounds nice as an add-on, but basic NX support in an HTML5 client should take priority. After all, that's what our sponsors asked for - and not a broker-/multi-server DMZ solution. It's fine to design the solution with a possible broker-add-on in mind, but please don't focus on the broker more than on the NX support.
Why stick to the NX support, if we have a native graphical backend that's html5 compliant.
Again: Because classic X2Go HTML5 support is what the sponsor wants to see. KDrive, Broker, Sound, Printer- and Filesharing - nice bells and whistles, but not what the sponsor wants.
NX is stable, NX is what they're used to, so they ask for it to be used. We're way past the stage where we could negotiate "Can't we just use KDrive instead of NX?".
I would also like to remind you that I don't consider KDrive production-ready for general use yet. It may work for Alex' customers, but last time I tried, I still saw quite a few quirks due to the session not recognizing that it is a remote session (showing popups that only make sense for a local user, granting permissions that a remote user should not have, etc.).
Those are blockers for a stable release and from my understanding, they need to be fixed in the Desktop Environments, not on the X2Go/KDrive side. And such changes are unlikely to get introduced/back-ported to already-existing long term releases of Linux distributions - which most sponsors/commercial users of X2Go are using.
So I doubt we'll see KDrive support becoming generally available until the next major releases of the most popular long-term distros. And that's not how long a sponsor should have to wait for a sponsored feature. Plus it might have a negative impact on their willingness to fund further work.
In a Pre-Corona world, I would have said I'd like to see results before or at the next Gathering. But if we get hit with another infection wave, who knows when the next Gathering will be, so that's not really an "anchor" for a time frame I would like to use right now. ;-)
The NX -> x11vnc -> NoVNC solution will always be worse (slower, more itchy and glitchy).
Maybe you could grab the NX output while still on the host (like, running a fake X2GoClient directly on the server), then push the output towards the HTML5 client the same way Alex' KDrive-HTML5 solution does? That could work as some kind of compatibility layer. That way, the DE would recognize a remote session (even though it's actually connected through 127.0.0.1 or ::1), so we don't have to deal with the quirks/wait for the fixes, yet you'd still only need one backend to talk to the HTML5 client, not two.
-Stefan
--
Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461
Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder
Amtsgericht München | http://www.phoca-gmbh.de HRB 196 658 | http://www.x2go.org USt-IdNr.: DE281977973
Hi Alex,
On Do 07 Mai 2020 15:29:56 CEST, Oleksandr Shneyder wrote:
Hello guys,
Looks like my E-Mail brought some excitement into the list :) First of all it was not my intention, I just wanted to share with you some of my thoughts. Second, I don't think that we will have something ready before the end of the year (depending on the resources I'll have). For sure, if some one wants to work into the same direction, you are welcome. I also want to add some of my thoughts about NX and X2Go. NX is obsolete. It was obsolete many years ago. Xorg is becoming obsolete as well. And X2Go is already obsolete too, because we are sticking to this technologies way too long. Don't understand me wrong, those are great technologies, which will be used for many years more by some people and companies, we should not drop their support and we should not stop to improve them. But we also should not things like NX slow down our development. Because majority of the users don't want NX. They want to use modern desktops and modern applications. And they don't care, that NX works better with legacy desktops and legacy X11 apps on 256K network, because they are not using them anyway and they have at home in worse case 10M network and even on their cell phones they have a good Internet connection.
@Stefan: I think it's great, that you finding sponsoring and it helps to support the project. But we also should not forget, to separate the wishes of our sponsors and our customers from that what is good for the project. We can't concentrate only on that what our sponsors want, because in this case at some point they'll be our only users. We should also think more about future and what should we do to win new users to the project.
All above: well said! I share your view on all points given.
At the end I want to give you some points I think I will work on in the next one or two years:
- Improvement of x2go kdrive: adaptive compression level, video compression for some regions, frame dropping, etc
Nice!
- x2gokdrive client - HTML5, Using OpenGL for image composition
Nice!
- Finally rewrite x2go client, multi session support, x2go kdrive client should be part of x2go client, etc.
Wait, for PyHoca-GUI, I'd love to have a standalone application. Maybe
provide the x2gokdriveclient as a libqt<foobar> shared lib and have
(a) a command line executable wrapped around it and (b) use it in X2Go
Client for rendering.
Thanks+Greets, Mike
DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
On Thu, May 7, 2020 at 3:30 PM Oleksandr Shneyder <o.shneyder@phoca-gmbh.de> wrote:
256K network, because they are not using them anyway and they have at home in worse case 10M network and even on their cell phones they have a good Internet connection.
Well, I do not like that state of mind. Just because a resource is there it is no justification for wasting it.
Also I know people running a X2go server in South America. I do not think they have good bandwidth and latency so there are use cases for the old technology.
Unfortunately you are right about X becoming more and more obsolete. I do not like it... So having the X in X2go is then legacy, too.
Generally you are talking about establishing another remote desktop approach while others try to keep the old approach alive. But there already are huge open projects that follow another approach, namely the whole vnc area and xpra. So why not integrate them instead of inventing the wheel again? What are the advantages of this approach?
Uli
Hi Uli,
Am 07.05.20 um 10:03 schrieb Ulrich Sibiller:
On Thu, May 7, 2020 at 3:30 PM Oleksandr Shneyder <o.shneyder@phoca-gmbh.de> wrote:
256K network, because they are not using them anyway and they have at home in worse case 10M network and even on their cell phones they have a good Internet connection.
Well, I do not like that state of mind. Just because a resource is there it is no justification for wasting it.
- I didn't say anything about wasting resources. NX is more efficient only when one using legacy application. In other case there is no efficiency.
- We are talking about majority of the users. I'm leaving in Mexico now, even here we have 4G everywhere and cheap fast Internet at home. And the situation improving with every year. I don't say we need to leave the people with bad Internet aside, I'm just saying we should more concentrate on the future.
Also I know people running a X2go server in South America. I do not think they have good bandwidth and latency so there are use cases for the old technology.
Unfortunately you are right about X becoming more and more obsolete. I do not like it... So having the X in X2go is then legacy, too.
yepp, I also don't really like the direction where it's going. I really like the ideas behind X11 - network transparency and all nice things. However X11 has a lot of disadvantages and I'm pretty sure you know about them not worse than I do. Anyway, unfortunately it's not for us to decide, we should work with that what we have.
Generally you are talking about establishing another remote desktop approach while others try to keep the old approach alive. But there already are huge open projects that follow another approach, namely the whole vnc area and xpra. So why not integrate them instead of inventing the wheel again? What are the advantages of this approach?
Same reason why I created X2Go in the first place. I looked on all existing solutions, didn't like any of them and decided to create a new one. And here we are.
Uli
--
Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461
Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder
Amtsgericht München | http://www.phoca-gmbh.de HRB 196 658 | http://www.x2go.org USt-IdNr.: DE281977973
On Thu, May 7, 2020 at 10:14 AM Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
The work Alex is doing is exactly what I discussed with him. My approach of providing X2Go through VNC in a web platform would only have been an interim solution.
I am still planning to work on a X2Go Session Broker based frontend for X2Go and will happily use Alex html5 client code (instead of NoVNC) in it.
This sounds all pretty much promising!
Well, AFAICS Alex is transferring (only) images/tiles from the server to client. Which which is not how NX works. So to support NX you either have to grab the (resulting) images at the server side and can then use Alex' code. Or you need a X server on the client side. Either in the browser or as a separate app running somewhere in the client-side network. The HTML5 client can then again grab the images from that server and display them.
Both approaches satisfy the "have a HTML5 client" but the first one loses all benefits of NX (from my POV there's no reason to use NX protocol anymore then) and the second is either a huge task (xserver in javascript) or requires a separate program running aside from the browser.
What am I missing that make you excited about all that?
Uli
Hi Uli,
On Do 07 Mai 2020 11:18:49 CEST, Ulrich Sibiller wrote:
What am I missing that make you excited about all that?
The device portability. I am not saying that X2Go Kdrive is the
solution to everything, but that it solves two problems:
- clients without Xserver
- at some later point: servers with Wayland based sessions
Mike
DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
-
Mike Gabriel -
Oleksandr Shneyder -
Stefan Baur -
Ulrich Sibiller