KDE over ssh

OMG

OMG, unbelievable

I am stunned, KDE is running over ssh

See the below screenshot

You can see ubuntu's violet terminals, ubuntu's global menu (close button on the left), Slackware 14 taskbar at the bottom, Ubuntu dashbar towards the left, Kinfocenter of KDE running from slackware, gnome system monitor of ubuntu running, KDE system settings running

Wondering, how it is possible? read ahead

Slackware KDE menu, ubuntu dash bar, KDE desktop

Slackware 14's firefox running in the right, Ubuntu's firefox running in the left, though KDE is running via ssh, it is surprising, titlebar, action bar (close, minimize and maximize) are using native ubuntu's

Another thing very surprising is, KDE over ssh using my powerful PC with nvidia card as x server and able to do 3d graphical effects!! whereas when I directly connect KDE slackware to monitor, it does not

 I love linux, :)

I recently assembled a low powered i3 system (just processor and a motherboard), swapped 4 GB from my old system(old system with i7 920 got 12 GB RAM upgrade) into new motherboard.

Removed a 500 GB hard disk from old system and swapped it to new system

OMG, slackware harddisk just booted into the new system

Now, I am having a single monitor so wanted to use both systems and don't want to keep swapping hdmi cables between two systems,

So here is what I experimented

To understand this see the following two important things on the setup (consider this assumptions applicable for my setup, which will vary with yours)

1. Slackware 14 on i3 3220 box is a headless ssh server (headless means no monitor, keyboard or mouse is connected) connected to home router through LAN cable with an ip address 192.168.1.5

2. Ubuntu 12.04 on i7 920 is a ssh client but has full fledged monitor, keyboard and mouse connected to it (as my Ubuntu box has nvidia GTX 460 card, it can handle tremendous GUI load), this box  is also connected to home router through LAN cable with an ip address 192.168.1.6


SSH Server Setup for X Forwarding

Now to enable X over ssh, this needs to be done in the ssh server which is slackware 14 box

Booted slackware 14 box, (while installing slackware I had enabled ssh). After that I opened  /etc/ssh/sshd_config

and changed X11Forwarding to yes from no and uncommented it


To do this, as a super user in slackware, where the ssh server is running I did this

vi /etc/ssh/sshd_config

 X11Forwarding yes

it should look like this

Then rebooted slackware 14 box


Testing X on SSH Client 

My ssh client is  ubuntu box.

To connect to ssh server I opened terminal and used ssh, gave my slackware credentials

ssh -X sankaran@192.168.1.5

You can see from the above, there is a capital X option after ssh, which indicates X to be forwarded/tunneled through ssh connection (ssh is considered secure)

192.168.1.5 is the ssh server which is my slackware 14 box

sankaran is the username in slackware 14 box

to check if the display is set correctly, tested this

echo $DISPLAY

it displayed


localhost:10.0

Now I ran xterm to check if X is forwarded properly

xterm

You can see from the below screenshot, how xterm is launched from slackware but its output got displayed in Ubuntu

Also observe the titlebar with left side close button, minimize button and maximize button


To show the difference between ssh session, I have given uname -a

you can see all these from below screenshot

Running KDE from inside ssh session

now that I showed how the ssh client and ssh server are configured and tested, it is time to put it to test

Just give startkde in ssh session, wow , wow, OMG

it runs a full fledged kde, unbelievable, isn't it

startkde

see the screenshots

KDE is starting from inside ssh session

See the kde taskbar at the bottom with kde icons and ubuntu dash icons in the left, omg

To show how KDE differs, I just clicked the folder applet and took the following screenshot

Observe network manager is showing a red colored x button in kde, who cares, as slackware is already connected to LAN and WAN, :)

To speed up things, we can do the following while doing ssh connection

ssh -XC -c blowfish sankaran@192.168.1.5

in the above C means compression is used while transfering data over LAN

-c blowfish tells the compression to use blowfish which is according to ssh manual a fast cipher for compression

All done, now slackware 14 does not have pulseaudio installed. I did not get any audio over ssh, though I guess if pulseaudio is installed it could piggyback audio through ssh

which means the audio through ssh will be my next experiment

Conclusion

One good thing about slackware 14 is it is an extremely powerful distribution, born to be a server (indeed a king of servers),

you may think,

Is Ubuntu or any other distribution can't do this?,
it can, but they launch desktop environment as soon as you boot, Ubuntu uses network manager to configure dhcp negotiation which works only after logging into gui.

All this means, I need to install Ubuntu server, which is a double work for me and I dont want to leave slackware anytime(fanboy, yes,  common, I am a  diehard slackware fan )

So so, Slackware 14, this flexible god of distributions does what you say, nothing less, nothing more, it exactly runs what you want. Just that

Whereas Ubuntu as a gui distribution helps my lazy mentality (LOL), now when the king of server distribution is plugged to Ubuntu client via ssh x forwarding, it is wonderful indeed

(Fedora, opensuse ... all these runs into gui ... so either ubuntu server or slackware 14 acts as a perfect headless box, slackware 14 has edge, it runs gui beautifully, as and when you want it to)

Reader of this blog, Hope you liked my exciting experiment

Enjoy

My slackware desktop screenshot

I put beach sand photo taken by phone as wallpaper for my slackware box, as it looked lovely

If you would like to get such photos and think it fits good enough to be a wallpaper for your desktop, go ahead

download from here

https://plus.google.com/u/0/photos/106224123724317246178/albums/5814357202337737873

Custom Ubuntu 64 bit Kernel 3.6.7 optimized for i3/i5/i7

This time my experiment is bit different, interesting and ambitious!

I upgraded my i7 RAM to 12 GB (Corsair Vengence 4 GB X 3) and running in triple channel mode (will tell what I did to the old RAM in another story :) )

I ran the kernel compilation in RAM mounted directory so that none of the files are read/written from/to harddisk while doing intensive kernel compilation. Infact processor scaled so well that kernel compilation took just under 19 mins which used to be 25 mins with harddisk. The real advantage is not the speed, but avoiding lots of read/writes to harddisk

To achieve this, I used tmpfs

The built script to build kernel 3.6.7 and utilize 10 GB of RAM for compilation is here

Use the above script only if you have above 10 GB of RAM

If you have less RAM use the script here

First, I created a directory and mounted that as a tmpfs. I gave a size of 10 GB RAM max for the newly mounted tmpfs.

The commands I used to create a directory and mount tmpfs is as follows

mkdir -p ~/BuildTmp

sudo mount -t tmpfs -o size=10G tmpfs ~/BuildTmp

To check the disk file size and monitor how the tmpfs is filling up, I used df -k

df -k

Calling df -k at various points of kernel compilation

 Towards the end of kernel compilation df -k reports 79 percent of 10 GB tmpfs, which is nearly 7.9 GB of RAM used!!

See the compilation time, not much gain in speed but small gain is a gain (a gain of 6 minutes)

Copying the compiled kernel debian files to harddisk

Installing the built kernel files

Unmounting tmpfs before rebooting

sudo umount ~/BuildTmp

Installing nvidia drivers for the newly built kernel, I downloaded 310.19 driver from nvidia.co.in

http://in.download.nvidia.com/XFree86/Linux-x86_64/310.19/NVIDIA-Linux-x86_64-310.19.run

Here is a video of how I built nvidia kernel module using recovery kernel, (video is shot using my phone and I am not a professional photographer, it is just for learning purpose I uploaded this video to youtube)

http://youtu.be/UUtvhMsIQ7o

or

https://www.youtube.com/watch?v=UUtvhMsIQ7o

It is simple, reboot and select recovery kernel, install nvidia driver using nvidia provided shell script, reboot into normal kernel

Here are the photographs explaining the same which was shown in video. (sorry for poor images with photo flash)

Select recovery kernel (second one usually in the boot loader screen)

 Booting into recovery...

Scroll down and select root Drop to root shell prompt

mount root filesystem read/write (and mount home if you have a separate home system) as root in recovery is mounted read only

mount -o remount,rw /
mount /home

Change to home directory where the nvidia driver is downloaded

run the driver using sh (replace the below file with whatever the driver filename using tab, :) )

sh ./NVIDIA-Linux-x86_64-310.19.run

Let nvidia installer launch

Accept nvidia license termns

Opt to uninstall previous drivers

Continue installation anyway? yes (Sorry it is blurred ...)

Register for dkms (what, no I say)

And that is it, rest by the installer ...

Install 32 bit compatibility openGL libs? yes of course

Let it run its way (won't you)

run nvidia-xconfig, yes man, yes, do it

Ah, give ok

cd
sync
unmount /home
mount -o remount,ro /
reboot

Unmount home and remount root read only, then reboot

From the boot loader, select the regular kernel (the first one, second is usually recovery kernel)

Now you should be into the gui with nice nvidia drivers, enjoy