Re: [X2Go-Dev] Fwd: [ArcticaProject/nx-libs] Document compression (#802)

2020-05-31 Thread Ulrich Sibiller
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)

2020-05-31 Thread Stefan Baur
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)

2020-05-31 Thread Ulrich Sibiller
-- 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

2020-05-31 Thread Mike Gabriel

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