Yes, I've joined the ubuntu train, and I'm travelling in the Kubuntu car (the caboose?). This will be, what, my fifth (or sixth if you count Knoppix, but I never put that on my hard drive) Linux distro since trying out RedHat 5.2 back in 1999. Previous to this I was using openSUSE 10.2 which is not a bad distro either and I always had my eye on SuSE. So, why yet another distro change?
MJL20080827 -- Update: I Just realised that this is one of my top-visited pages and it's a totally disorganised and incongruent pile of... What's worse is, I've never updated it since the promised update back in March 2007!
Let me clear things up (and save you wading through the whole article): If you want remote access to your openSUSE desktop from a networked thin client, then forget about X11, XDMCP, VNC or tunneling X through SSH. Use the NX protocol. You'll need to do the following:
The upshot: I've done this with a FreeNX server and Nomachine's NX client for Windows XP, and it all "just works", except maybe for some font issues with older X clients like emacs (install extra font packages from nomachine to fix that), and some transparency effect issues I noticed in kwin4, probably to do with X11 extensions missing in the NX client. Not a big deal.
Read the rest of this article for the boring background and laughable false-starts in my quest for remote desktops in X... <blush/>
This post was originally published at sinewalker.blogspot.com.au on 18 July 2005
In reference to this Slashdot question about Mainframe Culture
Appart from the obvious religious stuff about GUI (or lack of) and user-centred interfaces (or lack of), the biggest difference, and the biggest advantage that Mainframe brings is it's culture of process and change control. It is something you should strive to let your Mainframe masters pass on to the *nix/windoze padawans before they die of old age.
I am a *nix padawan, but, crocky technology asside, I'm frequently impressed by my Mainframe elders, their ability to deploy code to Production environments that works *the first time* nearly every time, and their ability to communictate technical changes necessary to fix broken code in the middle of the night in the 0.1% of cases where they failed to get it working first time.
Key values that I have picked up from my masters, and which should be inherrited by both *nix and PC/Mac enclaves are focused around Engineering principles. Mainframe guru's program like a civil engineer builds a bridge. No shortcuts are taken unless it can be proven that it is safe to do so. Testing is carried out in stages and test results must be submitted with the change request before a program migrates to Production. If a program must “abend” (Abnormal End) then it should do so noisily and with as much information as possible. If it finishes cleanly, little information is needed other than this fact.
These closely follow the advice Raymond has encoded in his book, but there is probably much more that your Mainframe gurus know that you should cherrish and extend to your newer team members.
Forget about the religious wars, the technology changes and the “focus” of your programmers on users or other programmers. Get the real truth from your Mainframe masters who have seen it all pass before them but have learned the hard way how to make a stable computer environment that stays up, even on cruddy mainframe technology. If their attitudes were adopted by people fluent in today's fantastic systems, all people would benefit.
The sad fact is that, in today's environment, especially after the dot-com cowboys set Upper Management expectations, following Process is just too slow, or too expensive. Convincing management that a bigger cost up front will result in a lower cost in the long run is also futile when mgt sees it as “normal” for computer systems to break. After all, their Windows machine on their desk has been doing that for 20 years now, so it must be normal, right?
What matters most to managers or clients when deploying new systems these days seems to be “time to market”, and the only consent to quality is that the IT dept/company follows check-list processes like CMMI or ISO9000 which do not address the real issues and put too much into the Process rather than the Result. Also, when the system breaks, it's typically at the expense of the IT company that built it, or was stupid enough to agree to use the off-the-shelf product in the first place, so there is nothing to drive a change of behaviour from the clients.