[FreeNX-kNX] The future of FreeNX, NX 3.0 and the distros

Leopold Palomo Avellaneda lepalom at wol.es
Sun Jul 8 22:48:14 UTC 2007


Dear people,

first of all sorry for the cross posting. I thought that the people will not 
be offended about that because it's important for both.

In the freenx list [1] have had a thread about the future of the freenx and nx 
3.0. Also in the pkg-nx-group [2] someone post about the the packaging.

FreeNX is based on NX core. The NX core, as someone in the pkg-nx-group list 
has posted has some problems to get included in debian, for example. Also, 
some potential maintainally problem to continue by the comunity.

After some private mails with Stefan Lippers-Hollmann and some long talk with 
Fabian Franz in the JornadesPL [3] there's a propose in the table that Fabian 
commented before and I would like to explain a bit more.

Follow the NX libs it would be difficult, as I have same. Why? well, in the 
first place, the NX-core is a derived work (xfree86 (2.x) , xorg (3.x)). 
There's duplicate code (ssh, samba) that, for example some distro will let 
but debian not. Also, if you want to develop something that use it, you 
depend in the NX core developers [4], and sadly they have show that doesn't 
take care about the people that send patches, security questions, etc.

Also, it must be consider that the NX technology is basically a patched 
solution for a thing that should be included in the Xorg core, because it's 
very integrate inside it. Howeber, because a license problems (include GPL 
code inside BSD ...) is not easy, or clear, o simple possible do it.

As Fabian commented me, and I realise, the main problems of the users showed 
in the list, is a security problems or simple, a derived problem of a 
incorrect package. In the same place, the mix of version of servers, clients, 
etc provoke a lot of problems. Stefan point to me questions about the 
robustness of the code, and the well know worked code that is integrated in 
the 2X branch. Also, point about the FHS compliance. 

The propose, the could be exposed in the next points:

1) Fork and a new project
We need to do a fork and create a complete project with: clients + servers 
+ extras. To do that, it's necessary a team. This project is very important. 
Also I would like to add that for the free soft comunity I think that it's 
strategically important to have it working like a charm. Having the clients, 
the interoperability between platforms, etc., the option to have thin 
clients, etc. 

So, the project should merge: freenx + 2X + NX . From where? Fabian thinks 
that it must be done from NX 3.x that is based on xorg. Stepan didn't have it 
clear, but I'm agree with Fabian. So the propose as cometed Fabian is to make 
a fork of NX libs of the 3.x version. Maybe a good place is the svn of 2X, or 
maybe another. I don't know.

From this, the idea is begin to eliminate all the duplicate code, specially 
the version of openssh and samba. Fabian told me that it could be do in a 
reasonable amount of time. Howeber, we must think that it will always be 
dependant of some files Xorg , so, every time that the xorg team change this 
files, all the libs (and project itself) would be needed to change. One 
approach than maybe could be done is to have some wrapper files (bsd license) 
included in the Xorg core, that provide the connectors to the functionality 
of this files and then only connect them. Think about it.

2) Release date
Martin Michlmayr could be very convicing with his work. I didn't go to his 
conference, but I know his experience and his ideas are good. Fabian consider 
that he wants to have some release time. Some about release every x time. I 
prefers sometimes the debian philosophy about release when it's done, but, 
many times it's desperately with long time releases. So, it could be 
interesting to have some release date.

3) Redefining an interface
Re-reading my notes , Fabian wrote about create nxproxy-easy component and 
write a reference client. Well, the idea is about this: maybe problems that 
the users complains also have to be about that feature (printing, sharing 
files,etc) or future features. The idea is have a well documented interface 
in the way that is someone want to add a feature could done it, but with a 
well documented and controlled interface. Fabian should prepare the 
complicated stuff of the server, and bring the option to other people to 
create pluggins, modules or whatever. As Fabian commented, 
- flexible and customizable, so that new developers can join easily.
- stable and not feature creep, so that features are not affecting the core 
functionality.
... it was never FreeNXs core task to provide sound or printing or file 
redirection. This should be easily pluggable and even not installable if you 
don't need it.

Also, design a new freenx to allow the usage of the 2x! and !M nxnode 
component.


Lastly, I think that probably it would be better to have a new name, a maybe 
begin to separately differentiate of the NX and !M names in the way to solve 
possible confusions o simple confusions.

Thank's a lot and waiting your comments,

Regards,

Leo


[1] http://mail.kde.org/pipermail/freenx-knx/2007-July/005473.html
[2] 
http://lists.alioth.debian.org/pipermail/pkg-nx-group/2007-July/000170.html
[3] http://www.jornadespl.org
[4] http://ww.nomachine.com

-- 
--
Linux User 152692
PGP: 0xF944807E
Catalonia
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/freenx-knx/attachments/20070709/d4274f7b/attachment.sig>


More information about the FreeNX-kNX mailing list