Hm.. I've tried several times and I just can't seem to get Cygwin to do the X-server on Windows emulation. I even followed several detailed guides exactly and it just kept saying "failed to connect to client" or something like that.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

Hm.. I've tried several times and I just can't seem to get Cygwin to do the X-server on Windows emulation. I even followed several detailed guides exactly and it just kept saying "failed to connect to client" or something like that.

Well, it did take a bit of putzing when I first grabbed it like 5 years ago. My crutch has always been "xhost +" in the original X shell that's launched on my workstation, then I can start all the X-Sessions I want from any target hosts and display them on my workstation as intended. I've installed cygwin on Win2K and later WinXP and both worked well.

Launch cygwin bash shell and start X:
startxwin.bat

In the basic shell that brings up:
xhost +

Then just have the system I want displaying in my X-window:
/usr/bin/X11/xterm -display $REMOTE_ADDR:0.0

Once you have that initial shell opened, any GUI based programs you launch from there will have their output displayed on your workstation because they should inherit the $DISPLAY setting.

Helps that I'm the only person in the entire company (well, up until last year at least) that even knew what "X" was. Don't need no steenkin' security there. And the Linux admin we hired back then is a good kinda Joe and wouldn't be one to take advantage of that. :-) For more paranoid execution, you can use "xhost [b]hostname_running_x_app[b]" to tighten it down a bit.

LOL! Just started looking in to this and sure as shoot, it works! Difference is that xterm isn't in a subfolder named X11 in newer linux Distros, like this one. :-) So the next thing to do is get a better Window Manager in the cygwin install. fvwm95 doesn't cut it after KDE!

Yeah, I've played with the DISPLAY declaration on a *nix box before. Need it when you typically run without a GUI but need to bring up some app that needs a GUI...

# > startx &
Then ctrl+alt+f1 (or whichever tty you're using)
# > DISPLAY=:0 ./boincmgr & (or something like that..haven't used it in a while)
ctrl+alt+f7

You can then do what you need to do, go back to the tty and do `kill %2', then `kill %1' and you're back to not having X running anymore.

One last thing about X.. tons and tons of non-Linux people mess it up.. it's XWindow.. there's no `S' on the end of it.

Wikipedia - XWindow

Hm..after some reading, that's where 'getty' comes from in the process list..he's one of the guys that created the whole X system. Makes sense now. I know Linux programmers have an interesting sense of humor, so I figured it was some kind of inside joke that nobody understood.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

I am very sorry from the late reply, I was very bussy with a water damage in my flat.

Have you gotten any feedback from folks installing v1.1 64bit Dotsch? I'm notice some things that I'm wondering about.

The feedback about problems is very spare in the moment. There was the pxeboot config files missing in the x64 distro, which is fixed. Some problems with the DHCP client and the CD did not eject correctly at x64.

64 bit installation
O Install to HD or USB key. Both fail to eject the CD. So I have to manually eject the CD so it'll boot the key or drive. It used to auto-eject with v1.0.

A other user has reported this also in my forums. I need to try to reproduce this.

O When it's done installing, the initial launch of the BOINC client produces no list of Projects to attach to. All that I find in the BOINC folder is an "all_projects_list_temp.xml" that has a size of 0. I can copy over a version of "all_projects_list.xml" from another install though and it works OK.
O With network configurations based on DHCP, I find my network doesn't connect until I go in and edit /etc/network/interfaces to add an "auto ethx" line for whichever interface I've got connected and "/etc/init.d/networking restart".

This was also reported by a user in my forum. Thnak you very much for your debuging. I will have a look, why reproduce this and write a fix on my homepage. - A other workaround is to start the DHCP client (dhclient) manualy via "sudo dhclient"

O If I launch the BOINC Client, and choose to Exit, it indicates it's going to shut-down BOINC completely. Even though it was running as a "service" when I started the Client. And it then fails to stop the "service" installation that's running anyways :-)

Sorry, I don't understand excatly. The BOINC client would be restarted after a exit automaticly after a 60 seconds timeout.

I'm happy to confirm you've got the persistence of hostname/network configs working. That has helped quite a bit for me with my USB installs.

Great !

One more little helper might be to more clearly indicate the release (64 bit versus i386) somehow after the install is done. I keep thinking customized desktop backgrounds for either. It takes a couple seconds for me to remember which I'm running on which systems, and BOINC itself doesn't include i386/64bit in the O/S display for Linux. (I'm up to 13 Dotsch-UX Hosts at this point. Only 5 of which are floating USB Keys. :-))

Great idea. I will make a customized background for each distro. Btw. "uname -a" will show you also the architecture...

Next step is figuring out how to hook up with an X-Session from a remote system. I've already surprised myself by finding I can SSH in. :-)

You can ssh to the diskless system from a system which has a X desktop running, and start a X11 programm. The ssh will tunneling X11 and display the X11 content on the system you initated ssh.

I am very sorry from the late reply, I was very busy with a water damage in my flat.

Really sorry to hear this, how is the cleanup coming, was it real bad? I do appliance repair, have seen a number of these situations, usually quite a mess. Hopefully it wasn't because of a fire...

Have you gotten any feedback from folks installing v1.1 64bit Dotsch? I'm notice some things that I'm wondering about.

The feedback about problems is very spare in the moment. There was the pxeboot config files missing in the x64 distro, which is fixed. Some problems with the DHCP client and the CD did not eject correctly at x64.

Any idea when you're going to impliment the patches into the distro? I had some issues installing the 1.1 version, and think I am going to hold off till 1.1.1 comes out. ;-)

---

I am very sorry from the late reply, I was very busy with a water damage in my flat.

Really sorry to hear this, how is the cleanup coming, was it real bad? I do appliance repair, have seen a number of these situations, usually quite a mess. Hopefully it wasn't because of a fire...

The flat is nearly try now. But a electrical drying and a renovation of the flat needed, if it's 100% dry again.
It was caused by a lot of snow melt which came into the flat due a deficiencies in the construction.

Have you gotten any feedback from folks installing v1.1 64bit Dotsch? I'm notice some things that I'm wondering about.

The feedback about problems is very spare in the moment. There was the pxeboot config files missing in the x64 distro, which is fixed. Some problems with the DHCP client and the CD did not eject correctly at x64.

Any idea when you're going to impliment the patches into the distro? I had some issues installing the 1.1 version, and think I am going to hold off till 1.1.1 comes out. ;-)

What issues do you have excatly by installing 1.1 ?
The workarounds for the PXE, Proxy and IP DHCP problems are addressed via a workaround on my homepage since today.

Lars, I mentioned them in my Server Farm thread a couple weeks ago, check em out there. Just some strange anomolies, some which appear to be covered by your patches.

---

Lars, I mentioned them in my Server Farm thread a couple weeks ago, check em out there. Just some strange anomolies, some which appear to be covered by your patches.

The DHCP ip assignment problems and the CUDA/NVIDIA problems would be covered by a workaround and the patch in future.
The auto login issues is a Ubuntu/GNOME related problem.

I have updated the other thread. I am very sorry for the late reply.

I've added a workinstruction for the final solution for the DHCP client problem to the chapter 4 of the documentation on my homepage.