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

Sat Jul 7 19:19:05 UTC 2007

I wonder if there is room for an alternative/simpler connection
protocol. It always seemed to me that the NX connection process was
much more complex than it needs to be. I think the idea of removing
the need fot the nx@ user is great. But since we now hove both an open
source client and server, is there really any reason to keep using the
existing NX connection procedure? This could make the whole process of
developing open source clients much simpler, and make the server side
easier to use.

I guess my point is there is no reason beyond compatabilty to keep
freenx a clone on !M. They seem to be moving towards the published
applications via RDP/VNC. I would suggest doing a poll of what the
freenx community needs, and designing the project around that.

Oh yea, and thats for all your great work!

On 7/7/07, Terje Andersen <terander at guard.zapto.org> wrote:
> Fabian Franz skrev:
> > 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").
> >
> hehe, too bad you missed 07.07.07 07:07 ;-p
> > 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.
> >
> >
> Good - will make it easier to draw the line between the old and the new
> redesigned one.
> > 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
> >
> >
> Great!
> > 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 ...
> >
> >
> yes! good choice :-)
> > ( 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.
> >
> Agree - will make it easier to sysadmins (like me :D)
> > - 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.
> >
> Agree, but the core tasks will have to be defined somewhere in the
> documentation so that both users/admins/devs can know what comes out of
> the core package, what is possible to plug in and enable/disable at
> wish, and finally what can be developed as a plugin.
> > 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.
> >
> >
> Agree. Priority 1 is a dev-team, but hopefully at later point in time we
> could create different teams for different needs. E.g. Dev-team,
> Doc-team, Website-team, Demo-team, etc.
> > 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.
> >
> >
> agree - those I've come across that had looked at NX/FreeNX found it
> (too?) hard, this will make it much easier to new devs to get up to speed.
> > KISS (Keep it simple stupid) is key here ...
> >
> >
> yes, agree again.
> > 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.
> >
> >
> Thanks, Alastair :-)
> > 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 ... ;-).
> >
> >
> Yes, maybe people on the ML could come forward with some suggestions ?
> > I've thought of Freetrix, but it might get us sued too easily ;-).
> >
> hehe, *lol*, yes - think your right on that one ;-)
> > Enjoy the release,
> >
> > cu
> >
> > Fabian
> >
> Thanks (as always) for you work!
>
> PS! Is there by any chance possible to do something about the website?
> Maybe use a CMS of some sort that eases content publishing, but that
> also has services for developers/translaters? I can install and
> contribute, but dunno what others think...
>
> /Terje
> ________________________________________________________________
>      Were you helped on this list with your FreeNX problem?
>     Then please write up the solution in the FreeNX Wiki/FAQ:
>   http://openfacts.berlios.de/index-en.phtml?title=FreeNX_FAQ
>          Don't forget to check the NX Knowledge Base:
>                  http://www.nomachine.com/kb/
>
> ________________________________________________________________
>        FreeNX-kNX mailing list --- FreeNX-kNX at kde.org
>       https://mail.kde.org/mailman/listinfo/freenx-knx
> ________________________________________________________________
>