What the? “Designed to make it easier than ever to control PC media from your desk, your lap–or even from the comfort of your couch”. So… if I use this keyboard’s Play button to try and play media that Vista’s DRM system thinks I shouldn’t be playing, does it administer an electric shock? What if I have the keyboard in my lap 😀 Ouch! No so comfortable now…
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:
Install an NX client on your remote terminal(s). Nomachine has free NX clients for Linux, Mac, Windows and Solaris (even some experimental ones for PlayStation 2 and Zaurus!). If your remote terminal is running openSUSE, you could alternatively get an open-source NX client from the build service (or ask yourself: I’m running X locally, so why don’t I just use good ole SSH and X11?)
Configure your NX client to connect to the openSUSE host, then log in and enjoy!
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/>
I don’t know how many other people get this issue, but it comes up at my work a bit: Some co-worker asks me if I know of a tool to do such-and-such, and invariably I think “well, that’s easy to do on Unix, but on Windows…”.
Then I remember Cygwin, and quickly find a Cygwin utility that does it, or can be scripted to do it with a small amount of work. So then co-worker asks if they can have a copy of this utility, and of course Cygwin is Free, so I say “sure, go download from www.cygwin.com.” Then they say, “yeah, but I don’t want to install all of Cygwin, can’t you just give me that one program?”
Well, the Cygwin command-line tools can be run from a Windows CMD.EXE shell, so this is quite possible to do. However, they all require the Cygwin POSIX layer, which at a minimum means I should also give them cygwin1.dll. But what other DLLs might the program use?
MJL2008-09-10T14:37+1000 Update: since this page gets a lot of hits, here’s the quick answer: use cygcheck, i.e:
Find it under Happy hacker discovery #2. Keep reading if you’re bored…
It is useful to have different versions of the JVM installed, for a number of reasons:
Different optimisation features from different JVM implementations
Different language features from different JVM versions
Java classes compiled with “Tiger” won’t run in “Mantis”…
It is also useful to be able to quickly switch between installed JREs/JDKs depending on the task at hand.
If I’m hacking in Linux, the JPackage project provides a much nicer solution to this problem, and the Linux distro’ I’m using (SUSE 10.0) uses JPackage. It’d be nice if there was an update-alternatives for Cygwin, but since there isn’t I’ve come up with this hack.
On the 32-bit Windows platform, JVM programs can only ever use up to about 1.5–1.6 GiB of memory in RAM per Java VM process. Allocating a heap size greater than this amount does not work. What’s going on?