I used massively the series 3.5.x, and I remember that they switched in 4.x to another design, more like a desktop remote surveillance, with optional ability to take over over controls.

I will look over current 6.x, then I will go back with details about how can be installed and what you obtain.

I did get it to start on headless server. First following this:
https://www.nomachine.com/FR10L02842

server.cfg:
CreateDisplay 1
DisplayOwner "<my user>"
DisplayGeometry "800x600"
AvailableSessionTypes unix-session-default (prepend this to the list)

Then it's necessary to follow this:

https://www.nomachine.com/AR06N00891

node.cfg:
DefaultDesktopCommand "/usr/bin/fluxbox"

That's the server.cfg, node.cfg in /usr/NX/etc/ not /etc/NX/server/localhost/.

At the moment I can't quite figure out how to get it to connect to a running instance of Xvfb, it just seems to timeout during connect.

https://www.nomachine.com/AR02M00840

Those instructions looks very plausible with what I remember about 4.x

------------------------

I fact, I have even a better idea how to try that. I will try to control my mini-PC, which I use(d) as router.

It is no problem to install, there is an option:

It's just nice to have a Slackware package, that's all.

EDIT: Sorry posts crossed.

True, would be nice, but we talk here about some proprietary software, with a specific way of setup and initialization.

That's funny. I just found Gerard's stuff on the same subject:
https://www.linuxquestions.org/quest...-a-4175526029/

So we have:

Gerard:
Me:
cgorac:
Now how many other ways can we find to fix incorrect documentation?

I just talked with a colleague about the eventual packaging of NX 6.x and he suggest that the single way is just to ship the extracted tarball into "/usr/NX" then to call the NX installer from install/doinst.sh

BUT, I do not think the resulted package could be also upgraded/removed, it will be just a shiny way to install the NX in via installpkg. Single shoot only.

Not easy to measure a country's real wealth these days, is it? Not when countries can create money out of thin air.

OK, then installed the x86_64 variant of NX in my usual work computer, and in my mini-PC the i686 one. Using in both
Then in the work PC I launched the NX Client, followed its steps, it discovered the mini-PC and connected like a charm.

----------------

What are the problems, in fact?

I'm afraid I'm not much use to you bifferos. I gave up trying to create a rock-solid terminal server on Slackware with x2go and xrdp and VNC because there were just too many flaky components. To sell this to a customer I needed it to be rock-solid, practically maintenance-free, and something another admin could deal with if I went under a bus. NX was the nicest by far, and the closest to what I needed, but the business didn't want to license 30 users.

I'm no longer in business either so the motivation to get this working just isn't there now.

Very nice this NX6, they evolved much since v4 ...

So, at the end of day, what is your problem?

I for one, I installed it on two computers and connected them, in no more than several minutes.

Oh, they wanted corporate features, but gratis?

There is no such thing like free lunch, right?

Quite, but there was always something more important in the IT budget.

It's all the same, because the home directory of x2goprint user is set to /var/spool in command preceding these in the x2goserver SlackBuild file. The install instructions in the x2goserver source tree use "~x2goprint". I guess the SlackBuild maintainer somehow omitted "~" when copying these instruction to the README file, and this is why the problem occurred to you.

If source code availability is a factor, then x2go is definitely an improvement over NX. On the other side, it is probably indeed the case that recent, binary-only, NX releases work faster. However, beware that also there are various other remote access solutions that, depending on specific use cases, could be vastly superior to NX - take for example NVIDIA GRID, that could stream visualizations or even games without significant lags/latencies.

Well good points taken!

Additionally, our brave friends to be aware, that in my humble opinion, there also another issues.

IF they try to invent a terminal server solution, like 100 users connecting to a single server, they should be aware of:

1. A computer running simultaneous 100 X sessions and KDE desktops should be a monster as power.

We talk about things like 100 cores, 200GB RAM, and a RAID optimized like hell for filesystem.

A server like this could cost dozens times more than 100 small and rather stupid computers, like my own mini-PC.

There is also the aspect that if a company has the will to pay tons of money for that monster server, most likely is next to nothing a specific RHEL license for, instead of some (non-verified so much) experiments made by yours, even with the help of the brilliant work of Slackware.

And, I do not know others, but I would be afraid to use on a $ 100,000 server, a SlackBuild given free of charge by an unknown benefactor found on Internet.

2. The network. Any connection eat bandwidth. There is another limitation of the max number of connections to a specific server, and there could help much an high optimized solution like NX, compared with a bare X session over SSH.

Overall, from my past experiments and work, I think you cannot go more than 80-100 sessions, IF everything is over a 1Gbps network.