Posted by George Wright Thu, 17 Aug 2006 17:58:00 GMT
Today is results day. I can’t say I wasn’t nervous about my results, but it seems they were exactly as I had predicted. I managed to get 4 As in Maths, Further Maths, Statistics and Physics, and also a grade 2 in STEP Maths I.
So now the panic is over. I have met the requirements of Cambridge’s offer and they have confirmed my offer for a place in October. Looks like I’m going to Cambridge for certain now!
Posted by George Wright Wed, 16 Aug 2006 22:24:00 GMT
For the past week I’ve been working on QtNX - my Qt 4 frontend to NXClientLib. Today I finished the bulk of it. A not so comprehensive list of features follows:
At the moment, most things work. Connecting to Windows NX servers is completely unimplemented at the moment, as is connecting to XDM sessions in UNIX. Same goes for remote VNC sessions. Again, the only key that can be used is the NoMachine key, but this will change soon.
As for getting hold of it - as usual it’s in the FreeNX SVN repository for which instructions on checking out can be found here. You will need to checkout /freenx instead of /freenx/trunk, as trunk doesn’t exist. The subdirectory that qtnx is in is nxclientlib/qtnx, and you need NXClientLib to compile it. See the README file for compilation instructions. I would ideally like as much feedback as possible from anyone who uses it.
Screenshots:
(More screenshots to be found in the extended body)
Read more...Posted by George Wright Sat, 05 Aug 2006 02:54:00 GMT
Today I started work on the XML parser. Things got interesting after I started to try and work out the meaning of the various elements in the structure that NoMachine’s NX client uses. There seems to be a fair bit of legacy stuff in there. Take, for example, the Images section:
“Disable JPEG Compression” doesn’t appear to change whether you disable JPEG or not, “Disable all image optimisations” doesn’t change, “Image Compression Type” is 2 for JPEG or 0 for both PNG and RAW, with “Use PNG Compression” to differentiate between the two.. “Image Encoding Type” doesn’t appear to change.. it’s all a frightfully illogical mess. In light of this I’ve taken the decision to axe my idea to tie nxclientlib’s configuration infrastructure to NoMachine’s client’s. I do this for two reasons:<option key="Disable JPEG Compression" value="0" /> <option key="Disable all image optimisations" value="false" /> <option key="Image Compression Type" value="2" /> <option key="Image Encoding Type" value="0" /> <option key="Image JPEG Encoding" value="false" /> <option key="JPEG Quality" value="6" /> <option key="RDP optimization for low-bandwidth link" value="false" /> <option key="Reduce colors to" value="" /> <option key="Use PNG Compression" value="true" /> <option key="VNC images compression" value="0" /> <option key="Windows Image Compression" value="1" />
0) The structure is a mess, and if there is some sort of strange order and logic behind it, I can’t figure it out and there’s no documentation. 1) If NoMachine changes their file format, we’re screwed.
Thus I will simply write my own (simple) XML configuration frontend. I have already got half way through writing a parser for the nxclient configuration format, so I won’t axe it as it may be useful in future to allow an “Import NX Client configuration” option. I shall implement that only when everything else is solid - it’s low priority as far as I’m concerned at the moment.
As for the other animals - that involves NXClientLib’s API. Adam Treat pointed out to me today that it was fairly pointless making the external functions in NXClientLib use standard datatypes as opposed to Qt ones, as the parent app has to link to Qt anyway. If anything, it introduces inefficiencies for a Qt app linking to it as the app would have to convert strings from QString to std::string, then NXClientLib would convert from std::string back to QString, which is a frightfully nasty state of affairs. Therefore I’ve taken Adam’s advice and I’ve changed the functions to use Qt datatypes instead.
In a similar vein I’ve removed the initial callback interface and replaced it with Qt signals which are emitted by nxclientlib. This is a lot cleaner than the old class-inheritence-pointer-callback thing I had before.
Finally - for all those holding their breath for a kNX - it’s not going to happen for a while. Due to the dependency of Qt 4, it’s going to have to be a KDE 4 client. This means that I will write the client now using only Qt 4 and then port it to kdelibs when it stabilises.
Posted by George Wright Thu, 03 Aug 2006 23:20:00 GMT
Today marks the first publicly usable release of NXClientLib. I have been messing around with it all day and finally have something that’s vaguely usable.
It’s basically complete. It supports starting new NX sessions as well as resuming suspended ones. It supports different image compression methods and just about anything else NX supports. I have also hacked together a very, very crude user interface in Qt 4 for testing purposes. This is by no means going to be released to the public - it’s just a quick hack at the moment to allow testing of the library. Gratuitous screenshot follows:
Lastly - the future. Well, NXClientLib isn’t quite finished. When I made my decision to link it to QtCore, I had always decided that the frontend would not have to link to Qt. Thus, all the functions that are called in order to invoke the NX session from the app should all take parameters that are standard in C or C++. I have not done this fully. Most of the functions are OK, but a couple slipped me by when coding at ridiculous hours and need to be made de-Qt. I also need to sort out connecting to a Windows server. Unfortunately, I don’t have access to any Windows NX servers so it’s going to be rather tricky. If anyone can give me access to one, I’d be very grateful. (Kurt - the one you gave me details for has never worked)
The other thing I need to do is code an XML configuration backend library in QDom for it to be able to read and write the XML configuration files that NoMachine’s binary NX client produces. After that, the kNX frontend needs to be written (I anticipate this will only take about a day to do).
As for trying it out - it’s been committed to FreeNX’s SVN server. Details on how to check out FreeNX are available at http://developer.berlios.de/svn/?group_id=2978 - except that you want to checkout the directory svn.berlios.de/freenx/ and NOT svn.berlios.de/freenx/trunk/ as it says. Instructions on how to use it are in the README file in the nxclientlib directory.
A couple of things to note: the menu entry for Quit does not work. I know this. I forgot to implement it and I’m fed up of coding for today, so that’ll have to wait. Same goes for the JPEG compression slider. Everything else should work.
Posted by George Wright Thu, 03 Aug 2006 02:32:00 GMT
As some of you may know, I’ve been spending the last week or so racking my brains as to how to generate a secure random number for use with NX. I had realised that I wasn’t going to be able to do this in a platform-independent way and had to use different methods for each platform (by way of #ifdef or something). Well, I decided to use my free Safari subscription (courtesy of O’Reilly for Summer of Code students) and slapped Secure Programming Cookbook for C and C++ on my bookshelf. Half an hour with chapter 11 and it all started to come together.
As anticipated, the book told me to use /dev/random or /dev/urandom on *nix systems, and I believe that /dev/urandom is random enough for my needs. After looking and analysing (and stripping down) the example code, I came up with the following:
#include <fcntl.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <errno.h> void fillRand(unsigned char *buf, size_t nbytes); static int devurand_fd = -1; int main(void) { unsigned long long int int1, int2; devurand_fd = open("/dev/urandom", O_RDONLY); fillRand((unsigned char*)&int1, sizeof(int1)); fillRand((unsigned char*)&int2, sizeof(int2)); printf("%llx%llx\n", int1, int2); return 0; } void fillRand(unsigned char *buf, size_t nbytes) { ssize_t r; unsigned char *where = buf; while (nbytes) { if ((r = read(devurand_fd, where, nbytes)) == -1) { if (errno == EINTR) continue; perror("spc_rand could not read from /dev/urandom"); exit(-1); } where += r; nbytes -= r; } }
The code basically fills up two unsigned long long int datatypes (64-bit length each) then splurts them out concatenated (and in hexadecimal). How exciting.
Posted by George Wright Wed, 26 Jul 2006 12:54:00 GMT
Today I imported the initial revision of nxlib to FreeNX’s CVS at http://cvs.berlios.de/cgi-bin/viewcvs.cgi/freenx/nxlib/. It doesn’t do much at the moment. For the minute it’s only actually interesting to developers.
Basically, I’ve managed to implement a wrapper around ssh using QProcess and redirect stdout/stderr to the controlling app using Qt’s signals. This makes things infinitely easier and more organised from a development perspective imho as it means that I can have a separate class to parse stdout/stderr. At the moment my only dependency is QtCore.
In the test/ subdirectory is a small test-case application to link against nxlib. It utilises QCoreApplication and works quite nicely. Note how small the application is; my intentions are for kNX to be similarly small (but of course with all the GUI stuff plonked in) as nxlib will do all the actual work.
One concern I have, though, is the elegance of my implementation of the public key handling. At the moment, I have a hard coded QByteArray with the default NoMachine public key (which most NX servers use) and if no path to a different public key is passed to the invokeNXSSH() function, it will write this QByteArray to /tmp/cert.pub and then pass “-i /tmp/cert.pub” to nxssh when it executes it. Otherwise it will pass “-i path-to-alternate-key”. I’m not a big fan of hardcoding stuff like that into source files, as if NoMachine changes the default key (which I think is unlikely) sources will need to be upgraded. I’m open to suggestions on how to improve this.
Another concern I have is generating a magic cookie for NX’s authentication. At the moment I’m thinking of taking the output from the system command ‘mcookie’, but this isn’t portable as Win32 systems don’t have this command. I would appreciate it if someone could throw some code for generating magic cookies in C in my general direction, as I have no idea about that sort of thing.
Posted by George Wright Sat, 22 Jul 2006 11:30:52 GMT
I just thought I’d give a community update on what is happening regarding my open source nx library, what decisions I’ve made, and where to find more information.
Firstly, I’ve decided to rewrite nxc. I have come to the conclusion that nxc is a bit bloated and far too complicated for the job (and Fabian backed me up on this), so I reckon instead of trying to decipher the code, I could get something better out in less time if I rewrite it. This rewrite will be called “nxlib”.
nxlib will be a small library which will link to QtCore from Qt 4. I understand this may anger lots of people, but I have a few reasons for doing this:
a) The NX library works almost entirely on parsing strings and string manipulation. I would like the QString class for this. It will make my life easier. b) I want QProcess for controlling the nxssh instance. c) QtCore is small, weighing in at 1.5MB.
For the moment, I’d prefer not to deal with any complex buildsystems, so for the minute it will be developed and compiled using qmake. This is because it takes me about 30 seconds to write a working .pro file for qmake whereas I anticipate it would take me ages to work out how cmake works (I’d like to use cmake in the end because that’s what KDE currently uses).
I have also been asked by many people whether I intend to allow the use of openssh as a drop-in replacement for nxssh. The short answer here is no. I say this because NoMachine have stated in their knowledge base that in future releases nxssh and openssh will not be able to be used as drop-in replacements for each other. See more here.
Obviously, the library will be written in C++ as it uses QtCore, but also because I want to split the whole thing down into several different classes like nxc currently does. It will make it more maintainable.
Finally, I’ve been working on documenting most things for the past few weeks. I have published all this documentation, mainly in PDF format, on my Summer of Code wiki at http://www.gwright.org.uk/soc/. Keep an eye here for various publications or work. If I do any public code releases, it will be there (and announced on this blog as well).
Posted by George Wright Sat, 22 Jul 2006 11:22:31 GMT
So for the past two weeks I’ve been down at Bisley shooting in various national competitions. We (Harrow School CCF) shot in the Schools Meeting which involved the Wellington (300 yards aggregate), Iveagh (500 yards), Victoria Tankard (600 yards) and the Ashburton Shield (big competition on the last day involving all three distances), as well as countless other trophies. We came 19th overall in the Ashburton, which is a bit low but at least we beat Eton. I got top score out of the team with 98 and 11 V-Bulls out of a maximum of 105 though, which was nice.
After that, three of us in the team decided to enter individually for the Imperial Meeting. It was fairly hectic, but great fun. I met an engineer from Cambridge whilst I was down there (who had stalked me by way of this blog) and was invited to their cocktail party which I unfortunately couldn’t make. I managed to (just) get the top score in the Grand Aggregate out of the three of us from Harrow, but nationally I did rather badly with 630 and 37 V-Bulls out of 705.
Ah well - it’s been a fun two weeks and now I’m back and coding on NX.
Posted by George Wright Sat, 24 Jun 2006 14:08:24 GMT
Today I gave a presentation to my LUG (the Greater London Linux Users Group) on NX and FreeNX. It started off fairly badly, as my ThinkPad flat out refused to talk to the projector, but after I realised that fglrx was being selfish and refusing to send data to the VGA port, it worked.
Anyway, the talk itself went quite well, but being the nervous wreck that I was, I sped through the talk in a matter of minutes - but I had the demo afterwards which went quite well. For once, kNX actually worked for the presentation! Hurrah!
In other news, A level exams have now finished! I’m now pretty certain I got 4 As, so that’s all OK. Just STEP and AEA Maths next week now… Thankfully they aren’t essential for me to get into university so it’s not a problem if I fail them (although I’d like to get good grades in both). I also now have time to actually do SoC work! :)
I’ll post my slides in PDF format soon.
Posted by George Wright Thu, 15 Jun 2006 12:04:29 GMT
So for the past couple of weeks I’ve had exams, and next week I start to get into the realms of lots of exams. Fun. As is probably obvious, I haven’t had time to do any Summer of Code stuff so that’s on hold for a while. The good news, though, is that after July 1st I should have lots more time to work on it (except I’ll be shooting every day at Bisley with the school team until the 21st) then after the 21st I have no commitments whatsoever so I can devote 100% of my time to SoC - which gives me a month, and a lot can be done in a month!
As for the work I have done so far on Summer of Code, I’ve started to look into how the whole thing works and I now have a pretty good idea of what’s going on. I have a Summer of Code wiki here where people can check up on what I’m doing. I keep that up-to-date regarding the SoC work I’m doing so if I don’t say it’s been done there, it’s not been done. :)
Time to take a bit of a break as I only managed to sleep for three hours last night due to Physics… :P
