Slashdot Mirror
XLiveCD: Cygwin and X For Windows On A Live CD
mallumax writes "OSnews is running a story
on XliveCD which runs an X server (from X.org) from the CD using Cygwin. Also included are awk, sed, perl, vim, bash, grep, other text utilities, and most importantly an OpenSSH client. XliveCD is being developed by University Technology Services of Indiana University. Now you can carry Cygwin with you! I have been looking for something like this for a long time. Torrent link."
- Take a CD to work and use X on any machine with a CD drive
- Use this as a framework to add more applications like dev tools, auditing tools or desktop apps (probably forking the project, but interesting)
- Use it to prove to the ill tempered that *Nix is not all bad and quite usable
- Find a way to port it to Flash drives and such
- Another valid use of BitTorrent
:D (the download of this iso that is)
Remember that this is an early version. The best uses are to come probably.US Democracy:The best person for the job (among These pre-selected choices...)
I'm sorry if I appear to be to be knit-picking but...
You have the client-server relationship wrong, a common mistake when talking about X windows.
The application running on Unix is the client to the X-server running, in this case, off a Windows machines.
Client examples: xterm, konqueror, Kmail, Evolution running on *nix
Server: X.org running on _Windows_ via Cygwin
--Aaron Greenberg
> What is the point?3 438 of it's ease of use.
The point is easy interoperability between *nix and Windows OSs. See my post at OSNews.com http://www.osnews.com/comment.php?news_id=9163#31
You can also find more info from from a paper published for the SIGUCCS of the ACM titled: Easy access to remote graphical UNIX applications for windows users Listed below is the publicly available abstract:
ABSTRACT
A barrier deters Windows users from evaluating graphical scientific software that runs only on remote UNIX systems. Graphical UNIX applications are based on X Windows. To make use of X applications, Windows users must install an X server, install communications software for connecting to remote UNIX systems, and configure their systems to display graphics from remote systems. This barrier can be removed by making use of an X server and communications software that run live from CD-ROM. This poster presents such a CD-ROM known as XLiveCD.
XLiveCD appears to users as an application that provides a command-prompt that allows them to log in to remote computers. Windows XP/NT/ 2000 users insert the CD into a drive and click twice in response to a wizard. A terminal window appears on the screen and provides a command prompt. From the command prompt users run the secure shell (ssh) to connect to a remote computer and launch applications. X graphics windows are forwarded automatically.
XLiveCD is based entirely on open source software and is available free for download. It is a Cygwin environment (from Red Hat, Inc.), including the X.org X server and openssh installed and modified to be run from CD-ROM. The home page is http://xlivecd.indiana.edu/.
I really, really wish the X guys hadn't used this terminology. But they did, so we need to keep it straight.
Just think of it this way:
A file server provides files to its clients. A print server provides printing to its clients. An X Window server provides graphical windows to its clients.
Thus, when you run any X application, it is a client to the X Window server. It asks the server for a window to display stuff in.
So, if you buy an expensive rack-mount server machine, and you hook up a thin client that lets you use a GUI, that thin client has an X server on it, and the X server talks to X clients that run on the server.
The neat thing is that in the other universe (the one where Spock has a beard), they call "clients" "servers" and "servers" "clients", but the X guys still did it backwards there so this confusion still applies.
Hope this helps.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
Are you kidding? I used to run xterm and Emacs over 2400 baud and it was tolerable,
Your example is inconclusive. Network speed has two independent components: bandwidth and latency. Just because your modem had poor bandwidth doesn't mean the latency was also bad.
And indeed, many aspects of the X11 protocol involve almost gratuitous round-trip queries that can make high latency a killer. Often it's aspects of the GUI toolkits that create this problem- a pretty effect that seems cool & fast on a localbox can be sluggish on the network.
Specific real-life example: in Evolution, you move an email from one folder to another, and the application draws a little translucent icon flying from origin to destination as a feedback indicator. It covers about 200 pixels distance, and for each step, the applcation downloads the remote image of the workspace under that position, alpha-blends a pixmap ontop of it, and sends the pixmap back to the viewer.
On a long-haul link, this can take MINUTES, during which you can't interact with any X11 programs. If you were running the program under VNC, however, the whole animation would be over before a screen update is even transmitted. While the user has missed-out on some eye-candy, this is far better than waiting through all the bidirectional traffic.
On the other hand, TightVNC is not usable for serious work even over a cable modem.
For truely serious work, it's not usable even on a loopback interface to localhost.
Even if everything else was the same, VNC has to refresh the whole screen,
False. VNC is an extensible protocol, so it can support arbitrarily intelligent update mechanisms. But even the original generation of VNC clients were smart enough only to update the screen regions that were actually changing.
(If your VNC experience has primarily been with the Windows server, you might not have noticed this, but that's because it was difficult for them to interface with the server without full screen-scraping and mouse-yanking, as Windows wasn't designed to allow concurrent users)