Should we continue using the term "NX"? #5

mikedep333 · 2015-03-04T13:25:18Z

If you look at debian/control, you will see package descriptions like:

Package: libxcompshad3
...
Description: nx-X11 shadowing library
NX is a software suite which implements very efficient
compression of the X11 protocol. This increases performance when
using X applications over a network, especially a slow one.
.
This package provides a library for shadow session support.

Should we continue using the term "NX"? Or should we switch all references to "nx-libs"? Or perhaps replace both NX and nx-libs entirely with some other name like "LBX2"?

mikedep333 · 2015-08-28T13:58:23Z

@gznget @sunweaver @nitomartinez @Ionic

I propose Xccc:

X11 Cached, Compressed and short-Circuited

Here is a proposed site design:
http://mikedep333.github.io/Xccc/
And the code for it:
https://github.com/mikedep333/Xccc

I believe that we need to rename nx-libs quickly (but not necessarily on the 3.5.0.x branch.)
Further reasoning is in the proposed site design.

sunweaver · 2015-08-28T14:17:35Z

How about Xc3? (Not that CCC is Chaos Computer Club in Germany/Europe, so there is a slight name clashing...).

mikedep333 · 2015-08-28T14:23:50Z

I was wondering that myself. I thought that "CCC" sounded familiar.

Some other piece of software is already called "XCC". But by using "Xc3", we can put the project name in the binary names (Xc3proxy and Xc3agent).

Ionic · 2015-08-28T18:50:28Z

I don't think a digit in the name is a great idea. Can easily be confused with a version number or other stuff.

I'd rather look for something like "NAX" (Network Accelerated X) or the like.

mikedep333 · 2015-08-28T21:30:38Z

I tend to agree with @Ionic . It can also create confusion with "X11" or "X2Go", but nx-libs is not specific to X2Go.

I still think Xccc is best because it highlights the 3 things that nx-libs does, but VNC only does 1 of (compression.) But my 2nd favorite so far is NAX.

If only the acronym "WAX" (WAN Accelerated X) didn't have a bad connotation (Wax is sticky, which means it is not fast moving. Also, "ear wax.").

Ionic · 2015-08-28T22:04:22Z

X11 actually is called X11 because it's the 11th protocol version. :)
(Although admittedly nowadays it's its own trademark.)

X2Go is "kind of okay" due to the the digit being surrounded by other letters.

WAX... there was also VAX, so...

I'm trying to come up with something involving "X", "accelerated" or "enhanced" and "network" (or similar), but haven't had a brilliant idea yet. Network enhanced X Technology? Better not. ;)

mikedep333 · 2015-08-29T23:34:28Z

@Ionic, yeah.

I am going to look through dictionary files for either a name or inspiration. Not that I have given up on Xccc, but there may be a better name.

Also, do not forget this lesson on naming software (or games):
The word Narbacular, which does not exist in any dictionary, was chosen primarily to aid in internet search engine results.

sunweaver · 2015-08-30T13:32:39Z

@mikedep333: Let's make sure that the new name is easily pronouncable and gives a fine melody when saying it. Xccc is a little tongue twister. Do we necessarily need to stay below 8 chars for the executables?

How about these, may: Xccc (nxagent), x3cproxy?

sunweaver · 2015-08-30T13:33:03Z

actually, xc3proxy...

mikedep333 · 2015-08-30T13:50:17Z

Hi @sunweaver,

It is true that Xccc is a bit long to say. However, I liked Xccc because it highlights the 3 things we do (Caching, Compression and short-Circuiting.) And "short-Circuting" (a term I made up for what we currently do to eliminate round-trips) is also a fine excuse for the executable having "Xcc" in the name.

Like I said, I intend to look through the dictionary files for more inspiration. I am open to other suggestions, including other names, and including adopting 1 name but having different names for the executables (like you suggested.) The terms "agent" and "proxy" are themselves confusing.

Even if we do adopt a different name, it may be a good idea to use the slogan "X11 Cached, Compressed and short-Circuited".

nitomartinez · 2016-01-20T08:33:17Z

My two cents:

NXC -> New X11 Channel Protocol

Pros:

It maintains the current NX name showing some history behind it
It uses the C which you seem to like.

sunweaver · 2018-02-27T08:59:36Z

I would like to bring up this discussion once more, so we maybe can quickly close this issue report.

As we are currently moving forward towards inclusion of nx-libs in all the major distros, I vote against a name change. At least not at this point or any near future point.

The term is coined and is associated with low bandwidth X11 connections. People have noticed, that we have been doing a shitload of work to clean up the code.

Enforcing a name change now would mean a considerable bunch of work. We should have done that 2 years back.

Anyone objecting to me closing this issue report? (If not, I will close it in two days from now).

sunweaver · 2018-02-27T09:00:29Z

@Ionic: @uli42: @mikedep33: @stefanbaur: @narenas: please take notice of #5 (comment)

And comment, if needed... Thanks!

sunweaver · 2018-02-27T09:00:48Z

@mikedep333: please take notice of #5 (comment)

And comment, if needed... Thanks!

stefanbaur · 2018-02-27T09:04:47Z

cf. https://en.wikipedia.org/wiki/Bicycle_shed_effect

TL;DR: Keep the name and close this report; or at least postpone the decision until the next major release.

Ionic · 2018-02-27T09:05:13Z

Rebranding would take a lot of additional (packaging) work, so... probably not wise.

Ionic · 2018-02-27T09:06:07Z

cf. https://en.wikipedia.org/wiki/Bicycle_shed_effect

Do we have another entry? BSE?

If compiled with -fsanitize=address this showed up when running startlxde: ==11551==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60d000018fbc at pc 0x7f270a9ed57b bp 0x7fff30ef3050 sp 0x7fff30ef2800 READ of size 204 at 0x60d000018fbc thread T0 #0 0x7f270a9ed57a (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a) #1 0x559dafcd5c93 in FindGlyphRef ../../render/glyph.c:179 #2 0x559dafcd705d in AddGlyph /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXglyph.c:71 #3 0x559dafccc0ff in ProcRenderAddGlyphs ../../mi/../render/render.c:1186 ArcticaProject#4 0x559dafcbd5a5 in ProcRenderDispatch /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXrender.c:1689 ArcticaProject#5 0x559dafcbc4ea in Dispatch /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXdispatch.c:476 ArcticaProject#6 0x559dafc4e9b0 in main /work/nx-libs/nx-X11/programs/Xserver/dix/main.c:353 ArcticaProject#7 0x7f2708e1d09a in __libc_start_main ../csu/libc-start.c:308 ArcticaProject#8 0x559dafc4f5d9 in _start (/work/nx-libs/nx-X11/programs/Xserver/nxagent+0x6e5d9) 0x60d000018fbc is located 0 bytes to the right of 140-byte region [0x60d000018f30,0x60d000018fbc) allocated by thread T0 here: #0 0x7f270aa1e330 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xe9330) #1 0x559dafcd646c in AllocateGlyph ../../render/glyph.c:348 This happens when two glyphs are compared via memcmp and the smaller one happens to be identical to the beginning of the bigger one. Newer render implementations use a sha1 hash instead of memcmp so this patch will (hopefully) be obsolete once render gets updated.

In compext Atom has the size of XlibAtom. Therefore calling functions of Compext.c requires to use/pass XlibAtom. Same for Window/XlibWindow. ==15438==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffffcdc0 at pc 0x5555556a81b5 bp 0x7fffffffcd10 sp 0x7fffffffcd08 WRITE of size 8 at 0x7fffffffcdc0 thread T0 #0 0x5555556a81b4 in NXGetCollectedProperty nx-X11/programs/Xserver/hw/nxagent/compext/Compext.c:4124 #1 0x5555557d0488 in nxagentCollectPropertyEvent nx-X11/programs/Xserver/hw/nxagent/Clipboard.c:1202 #2 0x555555723340 in nxagentHandleCollectPropertyEvent nx-X11/programs/Xserver/hw/nxagent/Events.c:3923 #3 0x55555571d4db in nxagentHandleProxyEvent nx-X11/programs/Xserver/hw/nxagent/Events.c:3007 ArcticaProject#4 0x55555571bb92 in nxagentHandleClientMessageEvent nx-X11/programs/Xserver/hw/nxagent/Events.c:2595 ArcticaProject#5 0x555555717dfc in nxagentDispatchEvents nx-X11/programs/Xserver/hw/nxagent/Events.c:1827 ArcticaProject#6 0x555555750813 in nxagentBlockHandler nx-X11/programs/Xserver/hw/nxagent/Handlers.c:437 ArcticaProject#7 0x5555556c1b5d in BlockHandler nx-X11/programs/Xserver/dix/dixutils.c:403 ArcticaProject#8 0x5555556d47ff in WaitForSomething nx-X11/programs/Xserver/os/WaitFor.c:232 ArcticaProject#9 0x555555665b22 in Dispatch nx-X11/programs/Xserver/hw/nxagent/NXdispatch.c:365 ArcticaProject#10 0x5555555ed760 in main nx-X11/programs/Xserver/dix/main.c:350 ArcticaProject#11 0x7ffff604909a in __libc_start_main ../csu/libc-start.c:308 ArcticaProject#12 0x5555555edc09 in _start (nx-X11/programs/Xserver/nxagent+0x99c09) Address 0x7fffffffcdc0 is located in stack of thread T0 at offset 32 in frame #0 0x5555557d0324 in nxagentCollectPropertyEvent nx-X11/programs/Xserver/hw/nxagent/Clipboard.c:1190 This frame has 5 object(s): [32, 36) 'atomReturnType' <== Memory access at offset 32 partially overflows this variable [96, 100) 'resultFormat' [160, 168) 'ulReturnItems' [224, 232) 'ulReturnBytesLeft' [288, 296) 'pszReturnData' HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow nx-X11/programs/Xserver/hw/nxagent/compext/Compext.c:4124 in NXGetCollectedProperty ...

Direct leak of 3 byte(s) in 1 object(s) allocated from: #0 0xb79e85d4 in __interceptor_malloc (/lib/i386-linux-gnu/libasan.so.5+0xeb5d4) #1 0xb770b635 in copystring /home/uli/work/nx/nx-libs/nx-X11/lib/src/ConnDis.c:96 #2 0xb770ba56 in _X11TransConnectDisplay /home/uli/work/nx/nx-libs/nx-X11/lib/src/ConnDis.c:229 #3 0xb776b4fd in XOpenDisplay /home/uli/work/nx/nx-libs/nx-X11/lib/src/OpenDis.c:215 ArcticaProject#4 0x63e2fd in nxagentInternalOpenDisplay /home/uli/work/nx/nx-libs/nx-X11/programs/Xserver/hw/nxagent/Display.c:608 ArcticaProject#5 0x63fa03 in nxagentOpenDisplay /home/uli/work/nx/nx-libs/nx-X11/programs/Xserver/hw/nxagent/Display.c:1140 ArcticaProject#6 0x694b5a in InitOutput /home/uli/work/nx/nx-libs/nx-X11/programs/Xserver/hw/nxagent/Init.c:305 ArcticaProject#7 0x5f7b11 in main /home/uli/work/nx/nx-libs/nx-X11/programs/Xserver/dix/main.c:278 ArcticaProject#8 0xb6f04b40 in __libc_start_main ../csu/libc-start.c:308 I have not investigated the exact location where an XFree() was missing but added multiple Xfree() calls whereever appropriate. Fixes ArcticaProject#951

mikedep333 mentioned this issue Mar 4, 2015

library clean-up: Don't build libNX_Xpm anymore. Use system's libXpm shared library. #4

Merged

sunweaver added help wanted question labels May 16, 2015

sunweaver added this to the 3.7.0.x milestone May 16, 2015

sunweaver modified the milestones: 3.6.0.x, 3.7.0.x Jan 19, 2016

sunweaver mentioned this issue Feb 24, 2016

[abrt] nxagent: GetULONG(): nxagent killed by SIGSEGV #85

Closed

uli42 mentioned this issue Apr 26, 2016

nxagent segfaults on session resume #118

Closed

sunweaver modified the milestones: 3.7.0.x, 3.6.0.0 Feb 5, 2017

sunweaver mentioned this issue Mar 7, 2017

kwin crashes with 3.5.99.4 #386

Closed

realsimix mentioned this issue Sep 11, 2017

nxagent segfaults (not always) if built with NXAGENT_RENDER_CLEANUP #512

Closed

sunweaver mentioned this issue Nov 22, 2017

switch to recent devPrivates ABI (as used in X.org's Xserver) #560

Open

pgotch mentioned this issue Mar 12, 2018

Coredump of nxagent when connecting #679

Closed

uli42 mentioned this issue Mar 14, 2018

nxagent crashes when moving the session window into another screen #677

Closed

JohnCaiJun mentioned this issue Nov 28, 2018

running nxagent in remote , how can i render 3d app on my local pc by local gpu? #739

Open

uli42 mentioned this issue Oct 9, 2019

malloc in signal handler causes deadlock #854

Open

realsimix mentioned this issue Jan 7, 2020

Segfault in nxagent after updating snapshot from 20191116 -> 20200106 #893

Closed

uli42 mentioned this issue Oct 7, 2020

nxagent: fix stack smashing #942

Merged

uli42 mentioned this issue Oct 18, 2020

Memory leak in ConnDis.c #951

Closed

uli42 mentioned this issue Jan 16, 2021

nxagent segfults with -geometry fullscreen #987

Closed

uli42 mentioned this issue Mar 2, 2021

Unresponsive session #970

Open

uli42 mentioned this issue Mar 16, 2021

x2goagent 3.5.99.26 crashes on connect #1009

Closed

uli42 mentioned this issue Nov 30, 2022

Update libNX_X11 to upstream's libX11-1.7.3.1-10-gd60ede78 #1037

Closed

uli42 mentioned this issue Oct 16, 2023

Segfault in libXcompshad #1069

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Should we continue using the term "NX"? #5

Should we continue using the term "NX"? #5

mikedep333 commented Mar 4, 2015

mikedep333 commented Aug 28, 2015

sunweaver commented Aug 28, 2015

mikedep333 commented Aug 28, 2015

Ionic commented Aug 28, 2015

mikedep333 commented Aug 28, 2015

Ionic commented Aug 28, 2015

mikedep333 commented Aug 29, 2015

sunweaver commented Aug 30, 2015

sunweaver commented Aug 30, 2015

mikedep333 commented Aug 30, 2015

nitomartinez commented Jan 20, 2016

sunweaver commented Feb 27, 2018

sunweaver commented Feb 27, 2018

sunweaver commented Feb 27, 2018

stefanbaur commented Feb 27, 2018

Ionic commented Feb 27, 2018

Ionic commented Feb 27, 2018

Should we continue using the term "NX"? #5

Should we continue using the term "NX"? #5

Comments

mikedep333 commented Mar 4, 2015

mikedep333 commented Aug 28, 2015

sunweaver commented Aug 28, 2015

mikedep333 commented Aug 28, 2015

Ionic commented Aug 28, 2015

mikedep333 commented Aug 28, 2015

Ionic commented Aug 28, 2015

mikedep333 commented Aug 29, 2015

sunweaver commented Aug 30, 2015

sunweaver commented Aug 30, 2015

mikedep333 commented Aug 30, 2015

nitomartinez commented Jan 20, 2016

sunweaver commented Feb 27, 2018

sunweaver commented Feb 27, 2018

sunweaver commented Feb 27, 2018

stefanbaur commented Feb 27, 2018

Ionic commented Feb 27, 2018

Ionic commented Feb 27, 2018