May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

VNC on Linux

News See also Recommended Links Recommended Papers X11vnc Vino
Rc-files VNC on solaris VNC on Windows VNC over SSH FreeNX Activating the gnome vino from the command line
The vncserver  modification .Xdefaults Starting VNC server Xstartup Humor Etc

If you are running the Gnome desktop then you already have a VNC server built in. Click Desktop > Preferences > Remote Desktop  to open the dialog, make sure that all four options displayed are clicked, select the password and you are in the game. For gnome users the built-in  Vino (VNC server for Gnome) is more efficient then stand-alone solution.  It is OK for older (non dual-core) PC and laptops too.  Please note that in RHEL 4 and OpenSuse10.2 vino  is not installed by default and you need to install the RPM manually to make it work.

The main problem with vino is that it does not support copy/paste with Windows client. In this sense you are better off using X11vnc

The same Remote Desktop option exists for KDE but krfb, a VNC compatible server for the KDE desktop, which implements this option is slow and very resource hungry. It is not recommended for older PCs (you might have up to 80% of CPU consumed by krfb).  That means that until version 4.0 KDE did not have a good analog to Vino.  Unless you have dual core CPU and a lot of RAM you should not even try krfb. Here is a typical post about the problem on a small desktop (NDS Engineers Support Forums): 

Hi, I'm running Linux Suse 9.0 like a VM with Vmware ESX 2.1
The kernel version is 2.4.21-246smp4G , the KDE version 3.1.4

Everytime that I connect remotely the krfb process use 100% of the CPU all
the time, check my top statistics, any ideas




top - 08:30:45 up 19:48, 3 users, load average: 1.69, 1.52, 0.77
Tasks: 83 total, 4 running, 78 sleeping, 0 stopped, 1 zombie
Cpu(s): 20.7% user, 76.9% system, 0.0% nice, 2.4% idle
Mem: 255072k total, 250764k used, 4308k free, 40168k buffers
Swap: 514040k total, 0k used, 514040k free, 108544k cached

2761 root 25 0 15712 15m 10m R 43.6 6.2 3:38.77 krfb
911 root 25 0 14784 10m 2420 R 34.4 4.1 42:31.89 X
2757 root 16 0 15712 15m 10m S 16.9 6.2 1:43.51 krfb
2797 root 15 0 17460 17m 14m R 1.0 6.8 0:01.23 kdeinit
1031 root 15 0 15308 14m 13m S 0.3 6.0 0:02.51 kdeinit

Therefore, a better option is to use X11vnc. I've found  X11vnc  to be a very reliable server.

Default desktop sharing on KDE 3.x is available but practically unusable because krfb, a VNC compatible server for the KDE desktop, is very slow and very resource hungry.

To configure desktop sharing you need to click the menu Configure Desktop -> Desktop -> Internet and Network -> Desktop Sharing. After that you can click all four option of unclick "Allow uninvited connected". Then you need to select your password. If you unclick "Allow uninvited connected" you should use long (longer then 8 characters), preferably  AOL-style ("double words") type of password like NNccru-831123 or XlonG-55927 -- "easy" password without a firewall means significant risk of intrusion. See also [PDF] The Desktop Sharing Handbook

By default, VNC is not a secure protocol. While passwords are not sent in plain-text (as in telnet), brute-force cracking could prove successful if both the encryption key and encoded password are sniffed from a network. For this reason it is recommended that a password of at least 8 characters is used. However, VNC may be tunneled over an SSH or VPN connection adding an extra security layer. SSH tunnels can be created from any clients.

RealVNC offers high-strength encryption as part of its commercial package.

KDE users can use any lightweight lightweight desktop like Xfce with classic VNC for remote access

Most GNU/Linux users choose GNOME or KDE for desktops without thinking. However, many alternatives exist, ranging from minimalist graphic environments in window managers like IceWM to entire alternative desktops, such as ROX. Of these alternatives the best-known and most polished is Xfce. Now at version 4.4, Xfce resembles a stripped-down version of GNOME, with carefully selected customization options and utilities, as well as a few thoughtful features of its own.

As detailed on the download page, Xfce is available in many distributions. In fact, a growing number of distributions, including Xbuntu, Dream Linux, and Zenwalk use Xfce by default. Alternatively, you can build Xfce from source code, or use its graphical installers. However, if you choose the graphical installers, read the documentation first to make sure you understand what you are doing, and the extra steps that you might have to take if you missed a cue from the installation wizard.

X11vnc provides the view of the view of real X display similar to WinVNC. Starting from version 0.9 it also contains several useful extensions pioneered by UltraVNC.

x11vnc is a program that allows one to remotely view and interact with real X displays (i.e. a display corresponding to a physical monitor, keyboard, and mouse) with any VNC viewer. It is similar to WinVNC and is designed to be compatible with all Unix variants and depend on a very small set of standard libraries. It supports a growing number of command line options, such as -nofb for dual- headed mode with Win2VNC. It is part of the LibVNCServer project.

Release focus: Minor feature enhancements

VNC Service advertising via mDNS (also known as ZeroConf or BonJour) is supported by the Avahi library. UltraVNC's TextChat, SingleWindow, and ServerInput extensions are supported (requires the UltraVNC or SSVNC viewer). Short aliases -find, -create, -svc, and -xdmsvc for common usage modes are added (e.g. to find a user's X display or create a new one with Xvfb). Reverse VNC connections (viewer listening) now work in -ssl mode. XDAMAGE use is automatically disabled if it appears to not be working properly (it often does not work with OpenGL applications like Beryl and MythTV).

Karl Runge

We strongly recommend TightVNC viewer as it includes a number of nice features over the official VNC client.  It can work iether with TightVNC server or with the standard server. An x11vnc project provides an Enhanced TightVNC Viewer package (SSVNC) for Unix, Windows, and Mac OS X with automatic SSL and/or SSH tunnelling support, SSL Certificate creation; and on Unix: NewFBSize, ZRLE, cursor alphablending, and low color modes support. Also on Unix the UltraVNC Text Chat, Single Window, Server Input, and 1/n Scaling extensions are supported. This bundle could be placed on, say, a USB memory stick for SSL/SSH VNC viewing from nearly any networked computer.

The Tight VNC modifications take effect in the client and server, but it’s the client changes that people appreciate most.  The user has three options to connect: best compression, fast compression and listen mode. Best compression uses JPEG compression to give you the fastest connection speed, along with the integrated data compression schemes. Fast compression uses data compression but doesn’t do the JPEG compression. All-in-all fast compression looks good and operates with reasonable speed. Actually if you are on 100Mb network on local LAN it does not matter :-).

All in all VNC is an amazing piece of free software that gets the job done.  Tight VNC makes a great program even better.

The TightVNC viewer is available as a pre-compiled binary or as source code. Only download the source if you are familiar with building packages or have an OS which doesn't have pre-built binaries. 

VNC Client Display Resolution

Depending on your VNC use, you may want to have a larger or smaller display than the default or a different number of colors. This often happens if you want to run the display full-screen or want to save your reduce the information over your network connection by choosing a smaller color set or resolution. The VNC server allows you to choose a resolution and color depth by connecting to different ports. Usually port 5995 is used, which corresponds to a 1024x768 resolution with 16 bit color, however you can choose any port 5991 to 5999.

Choose a resolution (800x600, 1024x768, or 1280x1024) and a color depth (8 bit, 16 bit, or 24 bit) and find the corresponding port in the following table.

Port Resolution Color Depth
5991 800x600 8 bit
5992 800x600 16 bit
5993 800x600 24 bit
5994 1024x768 8 bit
5995 1024x768 16 bit
5996 1024x768 24 bit
5997 1280x1024 8 bit
5998 1280x1024 16 bit
5999 1280x1024 24 bit

Checking local display setting

It is useful to know your local display's settings for choosing a VNC display. For instance, to make a full screen display you would match the local display resolution with the VNC display resolution. The resolution for the iMacs defaults to 1024x768 and the Suns in the Asprey lab default to 1280x1024. Here are instructions for finding the local display settings on several popular operating systems.

Top Visited
Past week
Past month


Old News ;-)

[May 14, 2012] Enable multiuser logins with VNC by Roderick W. Smith

Apr 24, 2012 | developerworks

VNC and X server architectures

Linux® uses the X Window System (X for short) as its graphical user interface (GUI). X is an unusual GUI in several ways, one way being that it's inherently network enabled. An X server is literally a network server program. Network server programs give client programs access to local resources, and this is true of an X server, as well. The oddity is that the "local resources" in the case of an X server are the display, keyboard, and mouse, which the user uses. In the most common configuration, the X client programs run on the same computer as the server. Thus, LibreOffice, the GNU Image Manipulation Program (GIMP), or other programs are X clients that use X's network protocols to accept user input and display output for users on the same computer.

When X is used over a network, though, the user sits at the X server computer, and X's clients are the programs that the user wants to run on another computer. This configuration requires a second network protocol to initiate the connection. This second protocol can be telnet, Secure Shell (SSH), or the X Display Manager Control Protocol (XDMCP). The server for this login protocol runs on the X client computer, and the remote login client runs on the X server computer. The remote login server launches X clients that in turn contact the X server. Figure 1 depicts this relationship. Dashed arrows denote session initiation. (In the case of XDMCP, the XDMCP client is built into the X server program.)

Figure 1. X remote access requires a client and a server on both computers
Diagram showing the relationship between X clients and an X server

This type of setup works fine on many local networks, but it has drawbacks. For instance, this configuration requires two-way network protocol initiation, which might not be possible through some firewalls or network address translation (NAT) routers. (SSH can tunnel X sessions, obviating this need.) Furthermore, although X servers are available for most platforms, they're not routinely installed on computers running Windows®. For these and other reasons, many sites prefer to use another protocol, the Remote Frame Buffer (RFB), which is implemented in the Virtual Network Computing (VNC) family of programs.

VNC is a cross-platform tool that can provide remote access to Linux, UNIX®, Mac OS X, Windows, and other systems from any type of client. With VNC, the user sits at the client computer and accesses a remote server computer. On Linux, the VNC server either mirrors the contents of the local X server's screen to the remote computer or includes its own X server that can operate independently of the one that manages the local screen. The result resembles Figure 2. Again, the dashed arrow indicates session initiation. This configuration eliminates the need for the reverse network connection, and because VNC clients and servers exist for so many operating systems, users can employ a single client program to access any server.

Figure 2. A VNC server includes an X server that can communicate with local X client programs
Diagram showing how VNC servers sends X server content to clients

The downside to VNC is that RFB authentication is based on passwords without user names. Thus, each user must launch an independent VNC server session and connect to that VNC instance by specifying the correct port number. This requirement might be tolerable on a single-user system, but is extremely awkward on a multiuser computer.

To work around this issue, you can link the two approaches. You can reconfigure your local XDMCP server to help the X server integrated in VNC provide the missing multiuser authentication (the resulting configuration resembles Figure 3). The dashed arrow indicates session initiation. Now, when remote VNC users contact the VNC server computer, they'll be able to enter their user names and passwords to access their own unique VNC sessions, so the computer can handle as many users as you like.

Figure 3. Adding XDMCP to a VNC configuration provides extra flexibility
Diagram showing how adding XDMCP to a VNC configuration provides extra flexibility

Configuring your VNC server

Several ways to launch VNC exist, including using scripts, linking VNC to your desktop environment using desktop tools, and using xinetd to listen for VNC connections. This last approach is the one described here, because it enables you to launch VNC so it can use your XDMCP server. Before detailing how to configure VNC to launch through xinetd, you must select a VNC server.

Selecting a VNC server

Several VNC server programs are available. (Resources provides pointers to several.) Some of the more popular options include TightVNC, TigerVNC, and RealVNC. This article uses TightVNC as an example. Unfortunately, configuration details vary from one server to another as well as from one distribution to another, so you might need to adjust the instructions provided here for your software.

Installing xinetd

Many distributions install the xinetd super server by default, but some do not. Because the method described here uses xinetd, you should install xinetd if it's not already installed. On most distributions, you can install xinetd by using the package system, such as apt-get install xinetd on Debian-based distributions or zypper install xinetd on openSUSE.

You might also need to configure xinetd to run. You can typically run it on a one-time basis by using its System V (SysV) startup script:

# /etc/init.d/xinetd start

Configuring xinetd to run automatically when the computer boots requires knowledge of the startup script methods for your distribution. Typically, you use a utility such as chkconfig (used in Fedora, openSUSE, and related distributions), update-rc.d (used in Debian and related distributions), or rc-update (used in Gentoo) to do the job, as in:

# chkconfig xinetd on
# update-rc.d xinetd enable
# rc-update add xinetd default

Type only one of those commands, or locate an equivalent for your distribution.

Note that xinetd may refuse to start if it doesn't have any services configured. Thus, you may want to put off launching it until you've configured xinetd to manage your VNC server.

Configuring xinetd

Servers that should be managed by xinetd place configuration files in the /etc/xinetd.d directory. Thus, to configure xinetd to handle VNC, you should create or edit a file with a name such as /etc/xinetd.d/vnc. (On some distributions, such as openSUSE, the VNC server package installs such a file.) Listing 1 provides an example.

Listing 1. An example VNC configuration for xinetd
service vnc
   disable     = no
   socket_type = stream
   protocol    = tcp
   wait        = no
   user        = nobody
   server      = /usr/bin/Xvnc
   server_args = -inetd -once -query localhost -geometry 1024x768 -depth 16
   type        = UNLISTED
   port        = 5900

This entry sets several xinetd options, most of which you should leave alone. Those you might want to adjust include the following:

The trickiest part of the xinetd configuration is setting the server arguments. You can use the arguments in Listing 1 as a model, but you might want to change some of them:

Many other options are available, and some vary from one VNC server to another. Consult the documentation for your VNC server to learn more.

Configuring your XDMCP server

Most Linux distributions configure their XDMCP servers to manage the local display and nothing else. To provide remote access, you must reconfigure your XDMCP server to accept access requests from the VNC server that runs on the same computer. The details vary from one XDMCP server to another. The three in most common use on Linux are the GNOME Display Manager (GDM), the Light Display Manager (LightDM), and the KDE Display Manager (KDM). Other XDMCP servers, such as XDM, require different adjustments than those described here. In any event, after reconfiguring your XDMCP server, you'll have to restart it.

Editing the XDMCP configuration file

If you're not sure which XDMCP server your system uses, you can identify it by searching a process listing for the string dm, as in:

$ ps ax | grep dm
  929 ?        Ss     0:00 /usr/bin/kdm
  962 tty7     Ss+    0:19 /usr/bin/Xorg -br :0 vt7 -nolisten tcp -auth \
30157 pts/3    S+     0:00 grep --color=auto dm

The first line of this output reveals that KDM is running, so you would have to edit this server's configuration file to enable VNC to use XDMCP. Most XDMCP programs have configuration files that follow a similar format. They include sections that are identified by section names in brackets, such as [xdmcp]. Lines following the section name set options using an equal sign, as in enable=true. Table 1 summarizes the configuration file names, section names, and options you must set to enable XDMCP on several common Linux XDMCP servers.

Table 1. Options to enable XDMCP support for VNC for various XDMCP servers
XMDCP server Configuration file name Section name Option
GDM /etc/X11/gdm/custom.conf [xdmcp] enable=true
KDM /usr/share/kde4/config/kdm/kdmrc [Xdmcp] Enable=true
LightDM /etc/lightdm/lightdm.conf [XDMCPServer] enabled=true

You might find the XDMCP section in your configuration file, or it might be absent entirely. If present, it might explicitly disable XMDCP support, contain commented-out options, or be empty. Whatever the original state of the file, you want to ensure that the XDMCP section is present and that this support is enabled. As an example, consider a KDM configuration to enable XDMCP:


Some distributions enable extra security measures that you might need to loosen. One of these is a firewall. Firewall scripts tend to be distribution specific, so consult your system's documentation to learn how to modify your firewall. You should ensure that localhost has access to port 177 and that your VNC clients have access to port 5900 (or whatever other ports that you use for VNC).

OpenSUSE uses an extra configuration file that controls some types of access, including XDMCP access: /etc/sysconfig/displaymanager. Open this file in a text editor and search for the following line:


Change this option to "yes". If it's left at "no", the login prompt of your XDMCP server is not visible when you connect to the VNC server. This change is not required on most distributions: Only openSUSE uses this file.

Restarting the XDMCP server

With your XDMCP server configured to accept remote logins, you must restart it. On distributions that launch X through a SysV init file, such as Debian and Gentoo, you can pass it the restart option:

# /etc/init.d/gdm restart

If your system uses the runlevel number to start X, such as Fedora and openSUSE, you'll need to switch to a text-mode runlevel (typically 3), and then back to the GUI runlevel (typically 5):

# telinit 3
# telinit 5

Be aware that either approach shuts down X, so ensure that you have saved all your open work in your X session before proceeding.

Testing and debugging the configuration

At this point, you should be able to log in from a remote computer using a VNC client. For instance, most Linux distributions provide a command called vncviewer; you can type:

vncviewer remotename

. . . to log in to remotename through VNC. The result, when VNC is configured and working correctly, resembles Figure 4. If you've configured multiple VNC sessions on different ports, you can specify the VNC session number by passing it as part of the hostname, as in:

vncviewer remotename:3

. . . to log in to session 3 (on port 5903).

Figure 4. When configured to work with XDMCP, VNC provides a traditional Linux login prompt
Screen capture of a traditional Linux login prompt in VNC

If you don't see an XDMCP login screen when you perform this test, you have some debugging to do. Some things to check include:

VNC security concerns

RFB is not a secure protocol; most VNC clients and servers don't encrypt their data. (VNC does encrypt its own passwords, but the method described here doesn't use these passwords.) Be cautious about where and how you deploy VNC. If you want to use VNC over an unsecured network, you have three choices:

Enabling VNC logins as described in this article opens at least two ports (the VNC port and the XDMCP port) to the outside world. You might want to restrict both ports with firewall rules to minimize the risk of abuse. Note that the XDMCP port (UDP port 177) need only be opened to localhost, so its firewall rule can be quite restrictive.


Overall, linking VNC and XDMCP is a useful technique to enable remote GUI logins to multiuser Linux computers. This method has advantages over using XDMCP directly in cross-platform environments or if working around firewall or NAT issues could be a problem. It's beneficial over more common direct VNC approaches on multiuser computers. If you use this method, be sure to consider the security issues. Be prepared to set up firewall rules to restrict unwanted outside access, and use encryption if your transfers traverse untrusted networks.

Roderick W. Smith is a consultant and author of more than a dozen books on UNIX and Linux, including The Definitive Guide to Samba 3, Linux in a Windows World, and Linux Professional Institute Certification Study Guide. He is also the author of the GPT fdisk partitioning software. He currently resides in Woonsocket, Rhode Island, and you can reach him at [email protected].

[Jul 23, 2011] TightVNC 2.0.95

TightVNC is a VNC distribution with many new features, improvements, and bugfixes over VNC. It is optimized for faster operation on slow network links such as modem connections, provides more configuration options in the server, features automatic SSH tunneling in the Unix vncviewer, and more. The modified servers and viewers are fully compatible with the original VNC software.

This release only updates TightVNC Java Viewer. This is the first public release of version 2.0. The viewer was redesigned and rewritten from the scratch. It features a Swing-based user interface, improved speed, and better code architecture.

[SOLVED] Re using vino-vncviewer - Ubuntu Forums

SOLVED] Re: using vino/vncviewer

> you can still run a stand-alone vnc server (does not use the current
> desktop). several, in fact. OR you can simply ssh into the box and
> run an X11 application and it will show up on the screen that you are
> currently using if you have an Xserver running there (linux in
> graphical mode, or windows with 3rd party software - ie
> hummingbird($$), cygwin(free) ).
> the vnc server route gives you the option of disconnecting and
> reconnecting from the session without the programs terminating
> (somewhat like remote desktop in windows).

SuSE has a very nice setup, but as my SuSE box is currently running
Mepis I don't have the recipe.

It runs the server out of xinetd, and you get a standard dm login screen.

Red Hat does it differently, and I have the recipe for something similar
because I've adapted it.

I run a script at boot time along with all the others in /etc/init.d

Here's the script:
summer@Kookaburra:~$ cat /etc/init.d/vnc
# If no config, do nothing
[ -f /etc/vncserver.conf ] || exit 0
function cfg()
sed </etc/vncserver.conf \
-e 's=#.*$==g' \
| grep -v '^$'

case "$1" in
cfg | while read user port options
do :
echo Starting session for ${user} on ${port}
eval passwdfile=~${user}/.vnc/passwd
if [ ! -f ${passwdfile} ] ; then
echo Cannot start session for ${user}, no passwd file
P=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/g ames
[ "${user}" = "root" ] &&
P=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bi n:/sbin:/bin:/usr/bin/X11
su - ${user} -c "PATH=${P} vncserver ${options} ${port}"
cfg | while read user port options
do :
echo Stopping session for ${user} on ${port}
eval passwdfile=~${user}/.vnc/passwd
if [ ! -f ${passwdfile} ] ; then
echo Cannot stop session for ${user}, no passwd file
su - ${user} -c "vncserver -kill ${port}"
echo ${0} '[start|stop]'


Here's the config file:
summer@Kookaburra:~$ cat /etc/vncserver.conf
# vncserver configuration: sessions to start automatically
# User display <options>
root :55 -geometry 1600x1200
suzanne :1 -geometry 1024x850

1600x1200 us the resolution of the screen I connect from. I run the
client full-screen. Colours can be a bit strange, but otherwise it works
very well.

You can also configure your dm to accept remote clients, then run X thus:
X -query garage.home.lan
I generally do that from inittab.

You switch with the usual ctrl-alt-F7 etc.

Finally, here is a great article that touches on this:
Just slip Ubuntu in in place of those other distroes whereever you like.

Setting Up VNC on RHEL 4

Calvin Webster cwebster "at"
Fri Apr 28 22:47:01 2006

I've been meaning to do this for quite some time. I figured this was a good opportunity to pass on my experience in setting up VNC on our network. VNC has become one of the most useful tools I've ever used. It allows me to do the work of several administrators by eliminating most of the time required to physically touch a remote computer.

I manage several interconnected LANs and network services spread across 4 buildings. Each building houses one or more offices and training facilities consisting of various blends of hardware/software platforms, applications, and users. If your network is anywhere near as diversified as ours, you'll need to do some research to get VNC running on all your platforms, but this should get you started using it in the way I think most people expect.

This collection of notes is very simplified, assuming the reader has reasonable Linux sysadmin skills and experience. Although the VNC documentation is comprehensive, some key configuration details seemed to be missing or hard to find for the setup we needed here. I've tried to cover them below.

MS Windows installations are pretty straightforward since it's a single-user OS. Just login as Administrator and run the InstallShield installer, then configure. I setup all our Windows machines with the Administrator password. Unfortunately (or fortunately, depending on your perspective) this means that only the sysadmin can connect to these machines. However, it also installs the VNC client with which users can connect to network servers. On our network we have Unix/Linux development machines to which they connect this way.

Any Unix/Linux machine that you can get GCC on will support VNC. Most Unix users I talk to expect to get a graphical login when they connect so I set it up to use the XDM login, just like it would if you were standing in front of the console.

I'll keep an eye on this thread for a while. If I've left anything out I'll try to fill in the blanks. One last warning: watch out for wrapped lines below.

--Cal Webster ## References:

Documentation for VNC Free Edition 4.1:

Other Multi-resolution Examples:

Documentation for RHEL 4:

## Notes:

32-bit color depths didn't work for me I'm offering only 8, 16, and 24 bit "True colour" for 32-bit setting is uneven for rgb and shift settings

24-bit setting evaluates to "32 bits per pixel" in the "VNC server default format"

Native X display (root console :0) uses default resolution of 8-bit 1024x768

## Goals:

To provide users with a method of connecting to servers with a graphical user interface from any workstation platform without saturating network bandwidth or requiring expensive, bandwidth-hungry 3rd party connectivity solutions (like Hummingbird Exceed).

To provide system/network administrators with a method of remotely supporting and maintaining server and client computers regardless of their host platform.

To provide the means to support on-the-spot training and troubleshooting during a helpdesk call.

## Security:

Examples shown below use somewhat relaxed security settings. You may want to use more paranoid settings if your network is at high risk. For example, you may choose to restrict VNC server to "localhost" connections and require clients to tunnel their VNC connections using SSH. You DEFINITELY want use this method if going over the public Internet. Bear in mind that this will limit available network bandwidth due to the encryption overhead inherent in the tunnel. If there is not enough available bandwidth for a given color depth, VNC will automatically throttle back to the most appropriate color depth.

If your network manager allows, and your perimeter and host security defenses are sufficient, you can take simple precautions without using SSH tunneling while maintaining a high degree of VNC functionality.

I highly recommend setting a password for the VNC "Native X Display" (root console :0) even if you have a secure network. See last item in examples. All other displays can use the XDM login authentication. The reason for this is that anyone could take control of a root user session if, for example, the sysadmin walked away from the terminal. The virtual displays are only ever visible to the person who made the connection so there's no danger of this.

... ... ...

Copy paste problem

Corné Beerse cbeerse at
Mon Aug 30 09:27:48 CEST 2004
Nepple, Bruce wrote:
> This happens in 5.4 and 5.3
> I'm running xfce3 under linux through vnc4
> I'm using nc with about 60 open sessions.
> Ctrl-c and ctrl-v don't work. They have worked
> in the past, but not now.  If I start a new
> nedit session (not nc), it doesn't work either.
> Middle mouse select/pasting works fine.
> I suspect that it is desktop/vnc related, but
> hopefully  someone will have an idea where
> to start looking.
I'm roughly sure it is vnc related... The vnc-session (viewer and/or server) do only transfer the select-buffer from/to the X11 side. Other buffers are roughly not touched.

With vnc (well with version 3 or related at least) the copy-paste actions between a m$windows desktop and a unix-vnc-server do work in `xterm` and related "older" applications but not in current applications that do have cut-copy-paste menu options. With xclipboard you can roughly see whats happening and you can use that to get things going, at least as current workaround.

I do know stuff has changed in this area with the newer vnc version 4 but I still have not tested details. I already do know it is related to the version at the server (remote) side. CBee

[Oct 3, 2007] VNC Copy and Paste Remote Desktop Sharing Problem - Ubuntu Forums

Re: VNC Copy and Paste Remote Desktop Sharing Problem

Unfortunately, "vino" (which is what the Remote Desktop feature uses) does not seem to support copy and pasting properly. However, you are not lost , You just need to use an alternate vnc server.

x11vnc seems to do what you want, you get it by adding the universe repositories ( It also performs much much better than vino and has many more configuration options.
By default it runs without a password, so make sure you get it setup properly to ask for one. If you need help making it start automatically with a script, let me know.

Also, the best VNC client and server for Windows is "UltraVNC" ( You should try it out.

Re: VNC Copy and Paste Remote Desktop Sharing Problem

I was able to get everyhting working. I posted how I did it here:

intangible posted an alternative using vnc4server instead of x11vnc here:

Here's where my information came from:


Q25 Can I cut and paste between the viewer and the server?
VNC supports copying and pasting of ASCII text in both directions, provided the viewer and server allow it. When the clipboard changes on the machine running the viewer, the changes are copied to the server and vice versa. Some notable exceptions:
  • X has more than one method of using the clipboard and different applications do it different ways. Emacs and xterm should just work. If you find that your X application doesn't work via VNC, you can generally use the xcutsel program to copy the clipboard between the different X methods. VNC uses Cut_Buffer0, so if you select text in Unix Netscape, for example, you may need to click 'Copy PRIMARY to 0' before it is accessible at the other end of the VNC link. You can use X resources to make the button labels more meaningful. For example, here's a script:
    exec xcutsel \
    	-xrm '*quit.borderWidth:0' \
    	-xrm '*quit.height: 1' \
    	-xrm '*quit.label:' \
    	-xrm '*sel-cut.label: Clipboard: out of netscape' \
    	-xrm '*cut-sel.label: Clipboard: into netscape' \
            -xrm '*font: -*-helvetica-*-r-*-*-*-*-*-*-*-*-*-*'

    Michael Witrant has written a program to do the transfer automatically. He writes:

    I'm glad to announce autocutsel version 0.1.

    People using xcutsel to copy/cut and paste between VNC and an X desktop might be interested with it. I was bored clicking on xcutsel's buttons to copy/paste between GTK apps on my VNC desktop and the Windows system running vncviewer.

    This tool regularly scans the primary selection and the cutbuffer 0. If one of them is changed, it updates the other one.

    I don't need xcutsel anymore and have a working cut and paste between GTK (through VNC) and Windows.

    You can get it there:

  • Java applets running in the browser cannot access the clipboard of the machine on which they are running, so the Java viewer has a clipboard button. This pops up a window displaying the contents of the remote clipboard, which should allow you to manipulate it locally.

[Apr 23, 2007] Set up the VNC Server in Fedora

  1. polarizer Says :
    November 14th, 2005 at 11:21 am

    I utilize vnc for years now and want to point out that there are some other implementations, such as tightvnc[1] or ultravnc[2], works better regarding bandwidth usage,visualisation or feature richness.


    polarizers 2cent

  2. Norman Rasmussen Says :
    November 14th, 2005 at 1:51 pm

    If you want a 'Terminal Services' like login interface. I suggest you try out VNC Session Manager. It supports creating new sessions, and disconnecting from them (and later reconnecting), etc.

  3. Bogdan Mustiata Says :
    November 14th, 2005 at 2:44 pm

    Or maybe it would be better to drop an eye on NX technology?

  4. polarizer Says :
    November 14th, 2005 at 2:54 pm

    Or on its free implementation at freeNX[1]


    polarizers 2cent

  5. Gnot Says :
    November 14th, 2005 at 3:46 pm

    Probably, I should have included those links in my post, but I'm glad you posted them. I have tried these VNC implementations myself, they work very well and they certainly have advantages over the original VNC. I wrote this small article because VNC is what comes with the Fedora installation media, so this is the new user's first acquaintance with remote computing.

    Norman Rasmussen:
    Your VNC Session Manager sounds very nice! I'll give it a try in the next days.

    Bogdan Mustiata:
    Right! I too believe that the NX technology is the future in remote computing. Less consumed bandwidth, native encryption support etc.

[Apr 21, 2007] Project details for x11vnc by Karl Runge

x11vnc is a program that allows one to remotely view and interact with real X displays (i.e. a display corresponding to a physical monitor, keyboard, and mouse) with any VNC viewer. It is similar to WinVNC and is designed to be compatible with all Unix variants and depend on a very small set of standard libraries. It supports a growing number of command line options, such as -nofb for dual- headed mode with Win2VNC. It is part of the LibVNCServer project.

Release focus: Minor feature enhancements

VNC Service advertising via mDNS (also known as ZeroConf or BonJour) is supported by the Avahi library. UltraVNC's TextChat, SingleWindow, and ServerInput extensions are supported (requires the UltraVNC or SSVNC viewer). Short aliases -find, -create, -svc, and -xdmsvc for common usage modes are added (e.g. to find a user's X display or create a new one with Xvfb). Reverse VNC connections (viewer listening) now work in -ssl mode. XDAMAGE use is automatically disabled if it appears to not be working properly (it often does not work with OpenGL applications like Beryl and MythTV).

Author: Karl Runge

[Mar 24, 2007] Project details for Enhanced TightVNC Viewer

Enhanced TightVNC Viewer 1.0.14 released
The Enhanced TightVNC Viewer package is part of the x11vnc VNC server project. It provides a native VNC viewer that takes advantage of new features in x11vnc, e.g. cursor alpha blending and automatic SSL tunnelling. Some features apply to any VNC server, e.g. automatic SSH tunnelling. Another goal is to provide a package that conveniently bundles everything needed for the user to have the enhanced viewer running quickly. This includes pre-built binaries of the viewer and utility programs for Windows and many Unix variants, and a GUI to configure and launch the viewer. The short name for this project is "ssvnc", for SSL/SSH VNC viewer.

Release focus: Minor bugfixes

Using port numbers lower than VNC's default port (5900) now works on Windows (for example,

Karl Runge [contact developer]

[Dec 06, 2006] Enhanced TightVNC Viewer TightVNC viewer enhanced with SSL tunnelling and other features.

C, Tcl, Unix Shell

The Enhanced TightVNC Viewer package is part of the x11vnc VNC server project. It provides a native VNC viewer that takes advantage of new features in x11vnc, e.g. cursor alpha blending and automatic SSL tunnelling. Some features apply to any VNC server, e.g. automatic SSH tunnelling. Another goal is to provide a package that conveniently bundles everything needed for the user to have the enhanced viewer running quickly. This includes pre-built binaries of the viewer and utility programs for Windows and many Unix variants, and a GUI to configure and launch the viewer. The short name for this project is "ssvnc", for SSL/SSH VNC viewer.

VNC server startup

You run the script vncserver that starts the server (the first time you run this script it will ask you about a new password for connecting to the server, you can change it later with vncpasswd. It also creates a directory ~ /.vnc with some config files in):

   nilsft@morgan:~$ vncserver

   New 'X' desktop is morgan:2

   Starting applications specified in /home/nilsft/.vnc/xstartup
   Log file is /home/nilsft/.vnc/morgan:2.log


It tells you that your new X desktop is on "morgan" on display "2" (you may get a different display number). It starts applications specified in "xstartup" and events are logged in morgan:2.log. You should make note of the name of the remote computer and display number. You need that later on.

Now you can skip to the section Client side to test things out before you start big efforts in customising the startup files

Customising the server

The "xstartup" file it created is pretty default and starts the twm windowmanager and you probably want that to be something else.

First you may want to kill the server running like this

   nilsft@morgan:~$ vncserver -kill :2
   Killing Xvnc process ID 27616

Now edit ~/.vnc/xstartup with your favourite editor. You especially want to edit the line saying

twm &

to something like

startkde &

or some other desktop environment or windowmanager. These off course have to be installed on the system from before.

The vncserver exports a desktop with the size 1024x768 and colour depth 8 as default. You can change this with the options -geometry and -depth. For example if you got a really small screen but want more colours, you'll write

nilsft@morgan:~$ vncserver -geometry 640x480 -depth 16

Now you can try out your new setup.

Client side, Window$

From the computer you are sitting on you start the clientprogram. On window$ this is just a small .exe file. It will ask you which remote computer and display to connect to. You enter the information you where provided when issuing the command vncserver on the remote computer - remember? Following the example from before you'll write this:


But this will only work if you're on a local network or something where morgan is a specific name. You should probably use the remote computer name including any domain ex:


It then asks you to enter your password, and then your X desktop should emerge on your window$ desktop. You can right-click on the vnc icon on the taskbar to select, for example full screen mode. (really nice, completely hides the window$ desktop, makes you think you really are at your linux box!)

If window$ against all odds! should show up with a blue screen and you're forced to reboot to get things working. Don't worry about your vnc connection. You just start the clientprogram and continue from where you where interrupted. So to actually end your vnc session you have to kill the vncserver on the remote computer as shown here Customising the server

It is remote control software which allows you to view and interact with one computer (the "server") using a simple program (the "viewer") on another computer anywhere on the Internet. The two computers don't even have to be the same type, so for example you can use VNC to view an office Linux machine on your Windows PC at home.

VNC is freely and publicly available and is in widespread active use by millions throughout industry, academia and privately.

I am using vnc (Release 3.3.3.r2-362) under SuSE 8.1.

If you don't have it installed get it from SuSE 'YAST2 Control Center': Install or Remove Software: Package Groups: X11: Utilities. You can then also try for 'Online update' to see if there is a newer version.

You will get files in:

/usr/X11R6/bin/ (Xvnc,vncpasswd, vncserver, vncviewer)
/usr/share/doc/packages/vnc (Documentation)
/usr/share/vnc/classes/ (Java classes for jvncviewer)

The script vncserver is a wrapper for Xvnc. I have changed the startup environment because I am using KDE. The change is on line 47; it now reads: startkde #&\n); The modified 'vncserver' is shown below.

. . .
. . .
    = ("#!/bin/sh\n\n".
       "xrdb \$HOME/.Xresources\n".
       "xsetroot -solid grey\n".
       "xterm -geometry 80x24+10+10 -ls -title \"\$VNCDESKTOP Desktop\" &\n".
       "startkde &\n");

chop($host = `uname -n`);

. . .
. . .

In my setup I wanted to have the vncservers to come up at boot time and keep their context even after disconnecting the vnc-viewer. Some people prefer to start VNC through inetd, but this always gives you a fresh desktop and is also slow in starting up. I don't think that in my configuration I have a security issue; the server is behind a firewall with only http and smtp ports open. The local network is purely private (home LAN).

In order to achieve this I created a boot script called xvncserver under /etc/init.d which is included below as xvncserver.

#! /bin/sh
# Author: Willem van der Mark <[email protected]>
# /etc/init.d/xvncserver	this Script
# /usr/sbin/rcvncserver		Root-Link to this Script
# /usr/X11R6/bin/vncserver	Program
# System startup script for vnc server
# LSB compatible service control script; see
# Note: This template uses functions rc_XXX defined in /etc/rc.status on
# UnitedLinux (UL) based Linux distributions. If you want to base your 
# script on this template and ensure that it works on non UL based LSB 
# compliant Linux distributions, you either have to provide the rc.status
# functions from UL or change the script to work without them.
# Provides:       xvncserver
# Required-Start: $remote_fs $syslog $network xdm
# X-UnitedLinux-Should-Start: $network xdm
# Required-Stop:  $remote_fs $syslog $network xdm
# X-UnitedLinux-Should-Stop: $network xdm
# Default-Start:  3 5
# Default-Stop:   0 1 2 6
# Description:    Start vncserver for remote control

# Check for missing binaries
test -x $VNC_WRAPPER || exit 5
test -x $VNC_MASTER || exit 5
test -r $VNC_CONFIG || exit 5

# Shell functions sourced from /etc/rc.status:
#      rc_check         check and set local and overall rc status
#      rc_status        check and set local and overall rc status
#      rc_status -v     ditto but be verbose in local rc status
#      rc_status -v -r  ditto and clear the local rc status
#      rc_failed        set local and overall rc status to failed
#      rc_failed <num>  set local and overall rc status to <num><num>
#      rc_reset         clear local rc status (overall remains)
#      rc_exit          exit appropriate to overall rc status
#      rc_active	checks whether a service is activated by symlinks
. /etc/rc.status

# First reset status of this service

# Return values acc. to LSB for all commands but status:
# 0 - success
# 1 - generic or unspecified error
# 2 - invalid or excess argument(s)
# 3 - unimplemented feature (e.g. "reload")
# 4 - insufficient privilege
# 5 - program is not installed
# 6 - program is not configured
# 7 - program is not running


prog=$"VNC server"

case "$1" in
		for display in ${VNCSERVERS}
		if test -a /home/${display##*:}/.vnc/passwd ; then
			rm -fv /tmp/.X${display%%:*}-lock
			rm -fv /tmp/.X11-unix/X${display%%:*}
			echo -n "Starting $prog on: ${display} -- "
			su ${display##*:} -l -c "cd && vncserver :${display%%:*} ${VNCARGS}"
			[ $? -eq 0 ] && echo $rc_done_up || echo $rc_failed_up
			echo -n "Vnc not initialised for user: ${display##*:}"
			echo $rc_failed ;
		for display in ${VNCSERVERS}
			echo -n "Shutting down $prog: ${display} "
			su ${display##*:} -c "vncserver -kill :${display%%:*}" >/dev/null 2>&1
			[ $? -eq 0 ] && echo $rc_done || echo $rc_failed
		$0 stop
		$0 start
		echo -n "Checking for service Vnc-Server "
		## Check status with checkproc(8), if process is running
		## checkproc will return with exit status 0.

		# Return value is slightly different for the status command:
		# 0 - service running
		# 1 - service dead, but /var/run/  pid  file exists
		# 2 - service dead, but /var/lock/ lock file exists
		# 3 - service not running

		# NOTE: checkproc returns LSB compliant status values.
		checkproc $VNC_MASTER
		rc_status -v
		echo "Usage: $0 {start|stop|status|restart}"
		exit 1

It is based on the skeleton provided in init.d and get its parameters from a file called 'vncservers' in /etc/sysconfig/. It contains 2 variables 'VNCSERVERS' and 'VNCARGS'. VNCSERVERS gives a series of 'screen number:user account' for each vnc-server you want to start. (not the root account; does not work, has not been tested, and it not recommendable). VNCARGS provides some extra parameters that will be passed to 'vncserver' or 'Xvnc'. This file is called vncservers. In this example the geometry of 940x705 prevents the vnc-viewer from clipping the Start bar in both Windows and Mac.

# The VNCSERVERS variable is a list of display:user pairs.
# Uncomment the lines below to start a VNC server on display :1
# as my 'myusername' (a legal user).  This user will also
# need to set a VNC password; run 'man vncpasswd' to see how
# to do that.  
# DO NOT RUN THIS SERVICE if your local area network is
# untrusted!  For a secure way of using VNC, see
# URL:
# VNCSERVERS="1:myusername ... ..."
VNCSERVERS="3:user1 4:user2"

# The VNCARGS variable contains arguments to vncserver (and Xvnc)
# which will be passed to all sessions; run 'man vncserver' or
# 'man Xvnc' to see which arguments are to be used.
# VNCARGS="-vncserversargs -Xvncargs"
VNCARGS="-geometry 940x705 -depth 16 -alwaysshared"

These options are then configurable in YAST2 'Editor for Sysconfig' under +etc: the following images


What is VNC?

VNC stands for Virtual Network Computing. It is remote control software which allows you to view and interact with one computer (the "server") using a simple program (the "viewer") on another computer anywhere on the Internet. The two computers don't even have to be the same type, so for example you can use VNC to view an office Linux machine on your Windows PC at home. VNC is freely and publicly available and is in widespread active use by millions throughout industry, academia and privately.

For more information, please visit

Do I have it in my system?

Type following command to check if you have the client and server installed in your system.

[tchung@tchung101 tchung]$ rpm -q vnc vnc-server
[tchung@tchung101 tchung]$


To configure vncserver as a service on your system, add yourself in following config file.

[tchung@tchung101 tchung]$ sudo vi /etc/sysconfig/vncservers

# The VNCSERVERS variable is a list of display:user pairs.
# Uncomment the line below to start a VNC server on display :1
# as my 'myusername' (adjust this to your own).  You will also
# need to set a VNC password; run 'man vncpasswd' to see how
# to do that.
# DO NOT RUN THIS SERVICE if your local area network is
# untrusted!  For a secure way of using VNC, see
# URL:
# VNCSERVERS="1:myusername"


Before starting vncserver as a service, let's create a vnc password with vncpasswd command.
Notice it creates a hidden directory .vnc under your home account with file passwd which contains your vnc password.

[tchung@tchung101 tchung]$ vncpasswd
[tchung@tchung101 tchung]$ ls -d .vnc
[tchung@tchung101 tchung]$ ls .vnc
[tchung@tchung101 tchung]$


Now let's start vncserver as a service.

[tchung@tchung101 tchung]$ sudo /sbin/service vncserver start
Starting VNC server: 1:tchung                              [  OK  ]
[tchung@tchung101 tchung]$

Take a look at the contents of .vnc directory now. You should have something similiar to following.

[tchung@tchung101 tchung]$ cd .vnc
[tchung@tchung101 .vnc]$ ls
passwd  tchung101:1.log  xstartup
[tchung@tchung101 .vnc]$

If you edit the script called xstartup, you will notice following comment in red.
Uncomment those two lines in red as shown below!!! Otherwise, you will get nothing but grey screen.

# Uncomment the following two lines for normal desktop:

exec /etc/X11/xinit/xinitrc

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
twm &


Since we've just edited vnc startup script, let's restart the vncserver.

[tchung@tchung101 tchung]$ sudo /sbin/service vncserver restart
Shutting down VNC server: 1:tchung                         [  OK  ]
Starting VNC server: 1:tchung                              [  OK  ]
[tchung@tchung101 tchung]$

So how do I connect to vncserver? Use vncviewer command in vnc client as following.

[tchung@tchung101 tchung]$ vncviewer localhost:1

Enter your vnc password and here is the result: Screenshot

To connect to a remote system with firewall, port 5901 needs to be open.
Add following line in red to open port 5091 and restart iptables service.

[tchung@tchung101 tchung]$ sudo vi /etc/sysconfig/iptables
# Firewall configuration written by redhat-config-securitylevel
# Manual customization of this file is not recommended.
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5901 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
[tchung@tchung101 tchung]$ sudo /sbin/service iptables restart
Flushing firewall rules:                                   [  OK  ]
Setting chains to policy ACCEPT: filter                    [  OK  ]
Unloading iptables modules:                                [  OK  ]
Applying iptables firewall rules:                          [  OK  ]
[tchung@tchung101 tchung]$

Recommended Links

Google matched content

Softpanorama Recommended

Top articles


Recommended papers



Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019