Proceeding with Arch Linux: Xdmcp, FreeNX, TwinView, no more zfs, etc.

First, the unfortunate news: I dont use zfs-fuse anymore. I never had data loss. But I ran into some problems with zfs-fuse running wild and almost freezing the system. I created a second pool /home/usr, because my /usr-partition was too small. And copied everything in it, and symlinked it to /usr. Shortly after that I had strange load peaks and partial freezes, with zfs-fuse running at up to 90% cpu-speed. I found out that the reason for this was man-db. So I copied /usr/share/man back to the primary harddisk and symlinked. This made the problem occur less often, but it randomly occured. I noticed that whenever it occurs I ran something like pacman or git or darcs – which are all creating lockfiles – which also man-db does. So my theory is that zfs-fuse has some problems with lockfiles. But I cannot verify that. Since the stable version of zfs-fuse has no inline-deduplication anyway, well, I maybe create a little backup-server with OpenSolaris and deduplicating ZFS in the kernel. Or I’ll wait until btrfs becomes stable – or zfs-fuse gets into the linux-kernel. Or maybe I really just write my own deduplication format which runs fully in usermode and just creates a bunch of archive files which point to blocks. I wonder why there are softlinks and hardlinks, but not yet „copy-on-write“-links in the common filesystems, at least for files (for directories I can imagine it could get a lot more complicated, but directory-entries shouldnt consume that much space). Of course, making it block-wise like btrfs and zfs is better, but of course harder.

Well, for incremental backups, there should be a lot of „userspace“-Solutions which run on any normal unix-filesystem – of course, you cannot have your snapshots on your working-partition without loss of a lot of space, but for most backup-purposes this should be sufficient. For my purposes it of course isnt quite, I have a lot of old „snapshots“ which can hardly be synchronized (except maybe with fdupes …). Maybe I will really write my own little backup-archive-format which just pushes anything into a huge file which save their blocks and anything. Shouldnt be too hard. But – of course  – I will first search for other solutions.

So well, enough of that then. Since I always forget my Screen-Adapter-Cable, but dont want to be always bound to the 13“-Screen on my mbp, I thought of setting up my thinclient. I activated xdmcp, adding the entry


to /etc/gdm/custom.conf. Xdmcp may not be the most flexible solution, but when combining it with Xephyr and Xpra, I am sure it can be made a lot more flexible. And on the other hand, inside the LAN, it is a lot better than VNC and RDP, it even gets comparably good results when using GLX. Unfortunately, Xdmcp is not very secure – but using it inside my home network (and the maths dept’s local network) I dont care about that because I simply trust these networks. Setting up an Xvnc-Server also is not hard, but mostly I am doing this manually only, by running Xvnc in a remote shell and forwarding the ports (and of course sometimes I use gnome’s desktop-sharing-feature). I still couldnt manage to set up an Xrdp-Server (except by tunneling X11 through VirtualBox, of course).

My favourite solution for this is FreeNX now, since it also performs well through DSL-Connections (and is usable through EDGE). Setting it up is not hard, using the tutorial in the Arch Linux Wiki. It uses SSH and should therefore be secure. It works well with other computers, unfortunately, apparently I cant get my thinclient booting properly -.- but this time I didnt forget my Screen Adapter Cable.

Which brings me to … TwinView … Which I use to manage the two screens now. It can be configured via the UI-Tool nvidia-settings – actually I was surprised not having to dig through the xorg.conf myself.

Furthermore, I removed a lot of stuff I didnt need anymore (which should be a good idea when /usr tended to be full …) – beginning with a lot of crap kde installed. The only KDE-Application I really use is Konversation now – simply because I am too lazy to switch to Xchat.

The next thing I am about to configure is trying to get the „Mobile Partner“ from my Huawei-UMTS-Stick working on Linux through Wine. The configuration through umtsmon is a mess, but at least it sometimes works – which doesnt apply to the setup through networkmanager. In theory, it should be possible to access the stick through Wine. The Software itself installs well, it just cant find the device. But there are hacks for Wine which can make Wine-Applications access USB-Devices. So well, its worth a try – and I am interested in what this software does when it found its stick – through which way will it provide network access? And will other processes inside Wine get access, too? If so, I can just cross-compile a little socks-proxy and be happy. If not … well, it gets harder, and maybe I’ll lose my interest to that topic.

At least this is not the most stupid way I was yet trying to get that stick work: I already forwarded it into a virtualized Windows … which is what I will maybe do again if anything else fails. Which reminds me of an older xkcd-comic:


Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

Du kommentierst mit Deinem Abmelden /  Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden /  Ändern )


Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )


Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )


Verbinde mit %s

%d Bloggern gefällt das: