FreeBSD Port: nxserver-1.4.0_1

[Eric Masson]

Robert Gilaard <zouk at tiscali.nl> writes:

Hi,

> I've noticed that nomachine has updated their freenx packages for
> different distributions. Now they even have amd64 native packages and I
> was wondering if that means we will see the amd64 version in freebsd
> anytime soon.

A port of 2.1.0 libs and freenx 0.6.0 is available here :
http://www.deweyonline.com/nx/freebsd.html

There's an ongoing work on 3.0 libs (search freenx-knx at kde.org
archives), freenx 0.7.0 has been released.

The FreeNX project will go under a complete rewrite soon, like explained
in the announce of the 0.7.0 release :

<20070707074543.77870 at gmx.net>
Okay, now we come to a section, which should answer all open questions:

- When will the next version be released? FreeNX development is so
unstable and unreliable. It almost feels like releases are done based on
mood.

The next version will be released in ~ 3 months if there is something to
release ( and there sure will be something ;-)).

That means we change to a time based release schedule now after a talk by 
Martin Michlmayr, former debian project leader, did convince me.

Next release date: 2007-10-10

I'm really really sorry for any inconvenience that "not released, but 
tagged" and "not released even though there were critical bugs" versions 
did cause you.

I know that there something did go terribly wrong from 2005-2006 and again
in 2006. And now the long delay for 0.7.0 again and still no new bugs 
fixed that occurred in my Question for Bugfixes thread.

I have made many many mistakes in the past and I'm sorry for that.

I think and hope a time based release schedule will fix at least all of 
_those_ issues.

- Why the fourth redesign? Won't this introduce many new bugs? Won't it
make the software not really unstable again? Shouldn't the software be
fixed instead of writing new things and introducing lots and lots of more
features.

First of all:

FreeNX was rapid prototyping, from a one night hack to what you have now.

There is one rule in prototype development: Throw the prototype away.

When I first learned that rule in university, I did not understand it.

But now that I see that the current code base gets more and more messy
and bugs cannot be really fixed and new bugs keep popping up and old
bugs get discussed on the ML again and again ...

... I am sick of it. With NX 3.0.0 it is necessary to do a redesign
anyway, so I decided to DESIGN it from scratch.

I'll take over some parts of the old code, but it'll be actually
DESIGNED and not just thrown together.

And for example that nx@ login will be optional from the start on so
finally our open source clients will be able to login directly and all
those SSH issues will at least with our clients be no longer an issue
and you can use public keys, smart cards, whatever to actually do the
login ...

( And if you need to use the commercial client, you can hack a modified
nxssh in. )

See also next question:

- Do you stick with bash or do you switch to some scripting language like 
python, perl, ruby, whatever ?

I'll stick with whatever is appropriate for the task.

As I know bash best, I'll stick with it for most parts, but there will be
also some parts written in C.

And the version will be so modular, that the language really does not 
matter anymore.

Btw. I have mostly heard:

Oh, wow its bash, it was easy to fix for me. And not: I don't know that 
language unfortunately.

So it is a good choice? I dunno.

I'll now try to keep all components really, really simple, so that they 
are not using any advanced things no one understands on first sight, but 
easily changeable and customizable.

The problems that freenx nxnode was not as stable and error free as !M 
nxnode were two:

- I first hacked it together and it has grown out of a 1 night hack
- I did not look at the actually source components how things are done, 
but just looked at client / server protocol. So I did write code without 
really understanding it.
- There had been some bad design issues, which had proven really hard to 
fix and which had lead to hard to trace race conditions after race 
condition.
- I did not actually design or think about it, but just looked at what !M 
did and tried to do the same as best as I could.

That is why I am now doing a re-design and I disagree that this is the 
fourth attempt. I had changed some major things in nxnode and nxserver 
before, but it was all still only code-change not code-rewrite.

The goals of the new design are:

- flexible and customizable, so that new developers can join easily.
- stable and not feature creep, so that features are not affecting the
  core functionality

While the features are incorporated into the design, they have the lowest 
priority in implementation.

- What will the redesign be based on? NX 3.0.0?

The redesign will be based on a stable fork() of NX 3.0.0:

Leopold did convice me now that slh is and always has been right. Sorry, 
for any misunderstanding in the past?

We need to have our own version of the NX tree, which we merge with new 
upcoming NX versions, when we are actually ready.

Merging it also has the huge advantage, that changes are easier seen and 
can be applied to the server / client code base too.

I however disagree that that should be 1.5.0, which 2x NX is based on. I 
would like to do the fork() with 3.0.0 as that has all features I ever 
wanted _and_ is based on x.org, which gives it slight chances of being not 
completely out of date, yet.

I'll talk with the 2x people, but I think it should be no problem to 
import the new version into their SVN.

- Why not just use and extend the GPL !M nxnode by 2x.

I am currently thinking of how to design the nxnode component that parts 
of the very stable version of !M nxnode can be also used with FreeNX.

- Who will be working on the redesign?

That is a very good question.

I'll do all the complicated stuff that I know best, but all other stuff 
will first of all be hook()able ...

And can be provided as additional plugins / hooks ...

On the other hand 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 this things are easy enough to be developed / changed and even 
released by someone else.

And I'll gladly share SVN access and I'll also accept any language you 
want to write this helper things in ...

But the thing is:

We need a team.

I won't be able to do it all by myself. That is another reason why I want 
a clean and documented design with well defined interfaces. No one could 
really work efficiently with the old code base, which got really bloated 
at some point.

KISS (Keep it simple stupid) is key here ...

Also well defined interfaces allow those components to be individually 
tested and even used, which greatly helps to do regression testing.

Think of now testing nxnode or nxserver for regression ...

... okay, lets talk about something else ...

It was a very nice surprise though that the documentation and string 
review comes along so well.

So I am looking positively into the future with lots of new developers for 
the NX 3.0.0 codebase incorporating changes very slowly into official 
x.org and lots of new developers doing components and developing plugins / 
hooks for FreeNX instead of screaming:

- I need feature x. 
- But I need Y.
- And I need z.

Once I have the interfaces designed people can already start working on 
the new components, though I think motivation will be the highest once it 
actually is working and they can also test their changes "live!".

If you really think that bash is the show stopper for 3rd party 
development, I'll learn another language, but so far no one has really 
screamed up, yet.

And first you have to show me some work done, because there was lots of 
talk and talk and talk, but not really many things were actually done. ;-)

I think once the first stable version of the redesign is out plus some
decent documentation, a name change is also in order to avoid confusion
with old things and outdated docs like nxserver --adduser ... ;-).

I've thought of Freetrix, but it might get us sued too easily ;-).

Enjoy the release,

cu

Fabian
</20070707074543.77870 at gmx.net>

Atm, I'm using !M server on a Debian box...

-- 
 C'est comme mon nain de jardin. Je préfère le laisser allumé la nuit,
 parce que si je l'éteins il ronfle, ce qui dérange mon portable Sony.
 -+- WoD in <http://www.le-gnu.net> : Nain porte quoi ? -+-