[FreeNX-kNX] Release: FreeNX 0.7.0 "Jornade SPL Edition VI+1" + QA: The future

[Fabian Franz]

Hello,

greetings from Girona, Spain after a really nice night out. ;-)

I'm (at least a bit) proud to present you with a 3 month delay the new
version of FreeNX.

Attention: Use it only with 2.1.0 or lower. 3.0.0 is _not_ supported.

Here is the ChangeLog:

07.07.2007 FreeNX 0.7.0 "Jornade SPL Edition VI+1"
        * Fixed the printing support for CUPS 1.2.
          Older versions of CUPS are no longer supported.
          * Note: You must do as root:

                  cp /usr/lib/cups/backend/ipp /usr/lib/cups/backend/nxipp
                  chmod 755 /usr/lib/cups/backend/nxipp

                  Or alternatively re-run nxsetup.

        * Added foomatic support.
          * Note: You might need to do: ln -s /usr/bin/foomatic-ppdfile
                  /usr/lib/cups/driver/
        * Added setting of CUPS_SERVER environment var.
        * Added automatic downloading of PPDs, if the client supports it.
        * Added configuration vars to tweak the new behaviour.
        * Added cups seamless support with no "use this driver?" dialogs at all.
          * Note: You need nxcupsd-wrapper on the client side for CUPS 1.2
                  clients.

                  Get it from nxutils repository.

        * Fixed Support for "Running" sessions - again.
        * Made the NXAgent exited with exit code 1 message more verbose.
        * Added support for nxipp to nxnode and nxsetup.
        * Added nxcups-gethost script for automatic usage in KDE.
        * Fixed RDP/VNC sessions. No application should be started for that type.
          (Patch by Bernard Cafarelli <voyageur at operamail.com>)
        * Added backingstore fix for older clients from Gentoo.
          (http://bugs.gentoo.org/show_bug.cgi?id=149298)
        * Fixed VNC sessions.
        * Fixed fullscreen sessions.
          (Patch by Gentoo Bugtracker)
        * Fixed --broadcast.
        * Added "passwd -u nx" to nxsetup to fix slackware.
        * Fixed respecting of enconding settings in case of rootless mode.
        * Fixed smb mounting in case nxclient sends the wrong port.
          (Patch by Jan Lockenvitz <jan.lockenvitz.ext at siemens.com>)
        * Fixed loadbalancing - was still using an undocumented variable.

So lots of bugfixes and some new features.

Grab it from: http://prdownload.berlios.de/freenx/freenx-0.7.0.tar.gz

The reason why I decided to have a 0.7.0 instead of a 0.6.1 (already
tagged 3 days ago) is that today is the 07.07.07 and when I tagged it, it
was 07:57 (yes, I missed 07:07, but I was still walking around in Girona
at that time, so I had to go with the "5").

I'm sorry that not all patches did go in in time and also NX 3.0.0 as a
backend is not officially supported, yet and most new features would not
be usable anyway, so use 0.7.0 only with 2.[01].0.

Also this is not a rushed release, but rather a long due one ...

Adding 3.0.0 to it would have possibly made the whole thing unstable if I
had rushed it in.

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