If it ain't broke DON'T FIX IT!

KDE 4.1 has a new "feature", a search engine called Strigi. It depends on a service called nepomukservices. The latter consumes about 95% of your CPU time. And there is nowhere that I can find any way to invoke strigi and make any use of it.

So, aphoristically, I am giving away 95% of my computing power to accomplish nothing.

OK, so let's turn it off. Fire up YaST and go to System > System Services (Runlevel). Sorry, no entries for either strigi or nepomukservices or anything like that.

OK, so then let's uninstall it. Fire up yast2 sw_single and find strigi. OK, done, change the checkbox to an X and proceed.

Not-so-fasto. It wants now to also uninstall all of KDE4 and plasma!!

Good grief!

OK, fuggedaboutit, locate strigi and rename the executables to trash_strigi, and then do the same for nepomukservices.

Done.

Look guys, I know you want to be creative, but please try to let something be optional until proven worthy and popular. The idea of uninstalling all of KDE 4 and plasma just to get rid of one useless search engine is ridiculous.

VNC - Virtual Network Computing

I have spent a number of hours over the last couple of weeks trying to work out Virtual Network Computing between two machines on my WiFi LAN. This post summarizes what I have found on my own, compared to what Google has found for me.

The VNC protocol is basic Linux and independent of the GUI software.

There are two ways of connecting: either a Remote Frame Buffer protocol that sends the desktop of the server or the original VNC protocol that sends the contents of an X-session established remotely on the server. While a person at the server display can see what is happening in an RFB session, the workings of the X-session are invisible.

http://www.realvnc.com/support/getting-started.html provides a good synopsis of the basic commands, but there were some glitches.

http://www.enterprisenetworkingplanet.com/netos/article.php/1470341 provides another good tutorial.

vncserver/vncviewer
This is the original, now TightVNC, protocol that comes with the distribution. Per the ''man'' page, vncserver is a wrapper script to launch an X server for VNC. Running it brings up av Xvnc session that only shows a shell terminal on the server machine.

krfb/krdc
This is a remote frame buffer GUI that comes with SuSE. krfb sets up a listening session on the server. krdc connects. krdc offers two types of connection: vnc and rdp. The former brings up the server's display. The latter is for remote control of Windows machines.

I have installed SuSE 11.1 (the latest) on both machines.

Review and Comments
vncserver/vncviewer

• I can connect to "m90" server, but only get an X session
• vncviewer will only connect to vncserver. It does not connect to a remote frame buffer server (e.g.,krfb)

krfb/krdc

• I can connect to m90 server but the presented screen is all patchy and unusable. I have tried all three "Connection Speed"s. The lower speeds end up with a pixellated display, but otherwise the results are the same: the mouse movements are halting and there are numerous different-sized different-colored rectangular patches over any text, and font colors vary. The results are essentially the same in both directions, although the problems while using my "p1610" as a server are not as pronounced as when using m90. This suggests the problem is the server speed. The patchiness is primarily on text. Graphics render fine.

http://192.168.5.2:5800

• |No response. Did various researches, opened firewall ports 5800:5802 and 5900:5902 on both machines. Just no joy. The result is the same in both Firefox and Konqueror. My guess is that this will only render an X session, which is not very useful (I can do as well with ''ssh'' if all it offers is a shell...

realvnc
http://realvnc.com/ offers a free version for download, which I have done. But it is just the usual vncserver/viewer X-session pair.|

I had earlier succeeded in getting a session with the machine upstairs {{{m90.Pilgrim.net, 192.168.5.2}}} using both {{{vncviewer}}} and the HTTP interface http://m90:5801/ on {{{konqueror}}}.

Remaining X-server Issues
The session is rendered as an X-session, not a desktop session, if vncserver is running. Which client is being used ((vncclient or krdc does not matter. You must have krfb up on the server to see the desktop.

With vncserver I do not know how to:

• Have the client's actions appear on the screen of the X server. All this can carry on in X and there is no indication on the screen. krdc actions do appear.
• See the existing server desktop. I only see the Xshell that comes up when I connect and any subsequent applications I open from the CLI in the shell. KDE Desktop, icons, etc. are all invisible.I can invoke KDE from the X-session shell prompt, but this then returns the pixellation and patchiness issues cited above, and again are invisible on the server display.
  
• Resize the windows in the viewer. I can bring up the menu and select resize but there is still no response. By contrast, krdc does a nice job of resizing the display to fit the client screen.
  
• Alt-Tab between the child windows. Again the Menu lets you park an icon manager and select windows there, but the Alt-Tab kind of function eludes me.
• Allow access to external addresses. This is just a matter of working through the firewall settings and the results in {{{dmesg}}} but at present we haven't gotten there.
• Allow access on my own machine. I can access M90 but not this machine and there are no messages in {{{dmesg}}} indicating the problem.

Tips

• Ensure your network does not have any IP conflicts. Each machine needs a unique IPA. //Duhhh//...
• Alt-F8 brings up the VNC viewer menu.
• Try the {{{-shared}}} option. When you make a connection to a VNC server, all other existing connections to that server are normally closed.
• You can run the viewer as either //user// or {{{root}}}. The permissions on the remote ("server") machine determine what you can do.
• You need to open a number of ports in the firewall to allow access here: TCP 5800, TCP 5900 as a minimum.
  

Checklist
Here is a checklist of access controls that can prevent successfull VNC sessions:
(With multitudinous thanks to
http://www.linuxquestions.org/questions/linux-newbie-8/vnc-connection-refused-435593/)
1. Make sure your router firewall allows VNC. Specifically, it should open the ports 5800, 5900. If your VNC display is on :1, you should also open ports 5801 & 5901. Similarly, if your display is on port :2, you should open 5802 & 5902, and so on.
In Guarddog, create these in the Advanced tab and enable Local to serve to to Pilgrim.net and vice versa (and the Internet if desired) in the Local section.

2. Make sure your Xwindows has access opened on those displays. To find out, do:
> xauth list
This results in:
P1610:~ # xauth list
P1610/unix:0 MIT-MAGIC-COOKIE-1 5e7c1e8f677366d772374530258c514e
M90.Pilgrim.net:1 MIT-MAGIC-COOKIE-1 5b6a01831f3e58b77218990dd62cdc1b
P1610/unix:1 MIT-MAGIC-COOKIE-1 5b6a01831f3e58b77218990dd62cdc1b
3. To find the external IP address of your linux machine, point your webbrowser (on the linux machine) to http://myipaddress.com/
4. Finally, note that you can point your web browser (on your linux machine) to the following website to check if your VNC server is accessible from the external world: http://www.gotomyvnc.com
5. And as usual after messing about with a firewall, go to
https://www.grc.com/x/ne.dll?bh0bkyd2
to make sure you are not showing anything you don't want to show.