Re: [X2Go-Dev] Fwd: [ArcticaProject/nx-libs] Document compression (#802)
On Sun, May 31, 2020 at 11:35 PM Stefan Baur wrote: > To me, this sounds like we should either change the value of the > compression setting to a new default when the slider is moved by the > user, or display a "recommended compression setting" next to it. I think, x2go should make specifiying the compression optional and rely on the built-in defaults otherwise. This means not specifiying compression in the nx options file if the user has not exlicitly selected a compression. For existing session configurations I don't see a way to distinguish if the user selected the compression on purpose or not if the compression is 16m-jpeg-9. Uli ___ x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
Re: [X2Go-Dev] Fwd: [ArcticaProject/nx-libs] Document compression (#802)
Am 31.05.20 um 23:14 schrieb Ulrich Sibiller: > In other words: in x2go you always have to select a clever combination > of link speed and compression while using plain NX you can stick with > the link speed and use the defaults. > > If you only touch the link speed setting you will always get 16m-jpeg. > > I am using an own software for connection (which I cannot make public > for legal reasons) and always stick with the defaults. I was not aware > of this x2go behaviour. But this might explain why I don't see the > performance problems I sometimes hear about from other people. > > So I consider this a bug. > > Developers: what's your opinion about this? Not a developer, but as the community manager, I would like to throw in my 0.02€ here as well: To me, this sounds like we should either change the value of the compression setting to a new default when the slider is moved by the user, or display a "recommended compression setting" next to it. -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-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
[X2Go-Dev] Fwd: [ArcticaProject/nx-libs] Document compression (#802)
-- Forwarded message - From: Ulrich Sibiller Date: Sun, May 31, 2020 at 10:58 PM Subject: Re: [ArcticaProject/nx-libs] Document compression (#802) To: ArcticaProject/nx-libs Cc: ArcticaProject/nx-libs , Author "nopack" in x2go becomes "none" in NX. And it means exactly what it says: do not compress images. This setting saves CPU cycles but required more bandwidth. Images are normally cached this so this is relevant only for the tiem an image must be transferred to the other side. All the things I documented are valid for plain NX sessions (without using x2go but other software). In NX - if you don't specify a compression method explicitly but only a link type - the compression method is derived from the link type. For ADSL you correctly expect adaptive-7 as I listed in the document. Using x2go things are a bit different. The NX code is the same and so are the built-in defaults. For ADSL this is still "adaptive-7". But x2go does always provide a compression type in addition to the link type. So that default is never used but overridden by the compression settings the user specifies in x2go's session configuration. So regarding compression you always get what you select there, in your case it is "nopack" (which becomes "none" at some point because of the internal naming of the parameter). In other words: in x2go you always have to select a clever combination of link speed and compression while using plain NX you can stick with the link speed and use the defaults. If you only touch the link speed setting you will always get 16m-jpeg. I am using an own software for connection (which I cannot make public for legal reasons) and always stick with the defaults. I was not aware of this x2go behaviour. But this might explain why I don't see the performance problems I sometimes hear about from other people. So I consider this a bug. Developers: what's your opinion about this? Uli On Sun, May 31, 2020 at 10:27 PM Anton Driesse wrote: > > Sorry, you lost me. > > I think you're saying nopack is the same as "no pack", but did you say what > nopack really is? > > Anyway, using nopack I do observe that the choice of link makes a difference. > > ADSL gave me reasonable update speed and quality; > with MODEM I expected quick update and poor quality, but I got slow update > and poor quality; > with LAN I expected and got slow update but high quality. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub, or unsubscribe. ___ x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
Re: [X2Go-Dev] Code formatting
Hi Melroy, On Sa 30 Mai 2020 01:16:46 CEST, Melroy van den Berg wrote: Hi Juri/Mike, Please let me know where you have any update regarding the VM host with Debian Buster. I'm also running a omnibus installation myself, which is indeed the most logical choice. I also found the option to use docker container of omnibus, instead of using the deb installation in the Debian VM. See docker hub: https://hub.docker.com/r/gitlab/gitlab-ce/ And readme: https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/master/doc/docker/README.md Disclaimer: I don't know the performance impact of using docker image as the GitLab instance vs directly running it on the VM. But I can imagine an upgrade will be easier by pulling a new docker image from a new tag vs APT, etc. Kind regards, Melroy van den Berg I'll grant you access to that VM tomorrow. Juri has created it. I want to double check its state before letting you in. Please don't wrap an extra docker around the Omnibus DEB. That's what the LXC container is for already. 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.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpY5xeP4S6CF.pgp Description: Digitale PGP-Signatur ___ x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev