Rob Mallory said: >My current project goal is to have solaris-x86 display servers (sunray, >citrix, nx, etc) hosting a >personal lx64 zone for each user who logs in. With >resource-controls, and a limited /pkg map, we >force users to utilize LSF or >Grid Engine to launch compute-intensive jobs into the farm.
@ rmallory I'm trying to get a Brandz world wide web related project off the ground myself (I've been held back by named / BIND not working and tailwatchd giving me problems). But now that I've heard your story I'm very curious, why does your fortune 500 company need 64-bit lx zones for their display servers? What's wrong with using 32-bit? A 32-bit display server for sunray, citrix, nx, etc. should work just as well as a 64-bit one, shouldn't it? For me, being able to emulate more system calls and newer Linux kernels (like a CentOS 5.1 image with a 2.6 kernel and PAE) is more important than whether or not it's 32-bit or 64-bit. I don't see why you would need more than 3 and a half gigabytes of RAM for a sunray / citrix Linux display zone, so I don't see why it's so important that we focus on the lx64 brand (like I said I'd rather focus on adding newer kernels and more system calls to the existing 32-bit implementation). I'm sure I'm ignorant and I'm probably missing something though. Can you please illuminate me on what the concrete benefits are of having a 64-bit lx brand vs a 32-bit lx brand other than that it sounds cooler to say "64-bit" than it does to say "32-bit"? I bet there's some kind of a PAE trick to get the 32-bit lx zone to see more than 3.5 gigs of RAM and the performance should be almost the same as it's still a 64-bit OpenSolaris kernel hiding underneath the lx brand translation layer. Am I right? -- This message posted from opensolaris.org
