For quite a while I had been working on SUSE Linux Enterprise Thin Client, which is Novell’s diskful Thin Client solution. It had a lot of challenging aspects, not least of which was fitting a minimal GNOME environment + apps onto 128MB of flash. That work is mostly wrapping up, though, and I’ve moved to a new team.

At the beginning of the month I started working on SUSE Studio, which is a web-based appliance builder for SUSE. I wanted to get out of my comfort zone a little, and it hasn’t disappointed there. We’re using RoR, which I am really enjoying so far. Ruby was ridiculously easy to pick up. Rails confused me at first with the amount of magic that it does behind-the-scenes, but there is a lot of information on how that works so getting up to speed wasn’t too bad. I bought Agile Web Development with Rails which has been very helpful as well.

Since openSUSE 11.1 has gone gold and GroupWise 8 has been around for a while, I decided to install openSUSE 11.1 with KDE 4.1 on my laptop. I use GroupWise and when I tried to install the GroupWise rpm’s, it complained about missing dependancies. I had to install the following software in order for GroupWise 8 to work:

openmotif, openmotif22-libs and libstdc++33

Once that was installed the GroupWise rpm’s installed without any problems

Today I spent the best part of the morning to configure a SLES 10 SP2 server as a simple router. I googled quite a lot and could not find a nice and concise post on how to configure SLES 10 as a simple router, so I thought I’ll write up my experiences in the hopes that it will help someone. Although this was done on SLES 10 I am pretty sure it will apply to openSUSE as well.

My setup is as follows: Local lan is 192.168.0.0/24 and I want a private lan on 192.168.1.0/24 so that I can run stuff like DHCP and PXE without upsetting everyone on the network. I have a SLES 10 server with 2 network cards: eth1 connected to the local lan and eth0 connected to my private switch. The local lan is connected via ADSL to the Internet and I need my private network to also be able to connect to the Internet.

The first thing did was to configure the ADSL router to send all traffic for my private network to the ip of the SLES 10 server on the local lan. In the case of our ADSL router it involved adding a custom route.

Next I started YasT on the SLES 10 server and under “Network Devices”, Network Card”, I selected “Edit” on one of the network cards and selected “Routing” and then enabled “IP forwarding”.

Then I edited the firewall settings and assigned the network card connected to the local lan to the external zone and the network card connected to the private network to the internal zone.

I did not enable masquerading as I wanted to be able to connect to machines on my private network from the local lan.

I then configured DHCP and DNS on the SLES 10 server and connected a machine to my private network and it was able to lease an IP address and resolve DNS queries. It did not however allow me to connect to anything outside the private lan.

After much googling and trying all sorts of iptables commands, I finally found a post that mentioned something about editing /etc/sysconfig/SuSEfirewall2. This can also be done via Yast, “System”, “etc/Sysconfig Editor”, which is the way I did it.

I had to change the following settings in Network → Firewall → SuSEfirewall2 :

FW_DEV_EXT: ensure that it contains the device of the external interface (eth1 on the local lan in my case)

FW_DEV_INT: ensure that it contains the device of the internal interface (eth0 on the private lan in my case)

FW_ROUTE: yes

FW_MASQUERADE: no

FW_FORWARD: This was the magic line for me. This needs to contain a space separated list of what you will allow. In my case I just put 192.168.0.0/24,192.168.1.0/24 192.168.1.0/24,192.168.0.0/24 192.168.0.1/24,0/0. This allows all traffic between the local lan and the private lan and allows the private lan to connect to the Internet.

The comments and help in YasT is comprehensive and made it quite easy to understand the meaning of each of the fields.

I had to restart the firewall after I made the changes.

I hope someone finds this useful.

1. The distro_target attribute should be turned into some standard distribution identifier to make it really useful. The CPE looks like a good candidate.
2. The spec does not say how to handle repositories of type unknown to the client. They should be ignored, but the type attribute of <repo> is currently optional so the type does not need to be known when refreshing the service. One solution could be to make the type attribute required, another could be to require that the client removes any repositories comming from a service that are of unknown type. The latter seems to be cumbersome, i would go for the former.
   
3. It might be worth to add the examples from this Duncan's post to the page (they're much better than those of mine :O).
4. The specification should not be kept solely as a wiki (should not be editable by broad public; version control is problematic, etc.). Any suggestion where it should be instead?

I am using LaTeX and beamer class to make presentations and posters. A short introduction to start with latex is available. Sometimes I am using LaTeX just to produce eps/pdf text boxes and after that Scribus for poster layout. In the last development version of Scribus, which is 1.3.5svn, there is possible to use latex source/expressions directly in document, so is not necessary anymore the aditional step to create eps/pdf text boxes.

For OpenSUSE there is the last version here:

http://software.opensuse.org/ymp/home:mrdocs/openSUSE_11.0/scribus.ymp

but I don't want to replace 1.3.3.12 stable version, so I will install the latest development version in my home directory

Warning: The documents saved in 1.3.5 will not be back compatible with the other versions, more here: http://scribus.info/svn/Scribus/trunk/Scribus/README

Let's install the last development of Scribus (it is very stable for what I need, I didn't have any problems with it):

$ mkdir ~/aplic/scribus_135
$ mkdir ~/tempsrc
$ cd ~/tempsrc
$ svn co svn://scribus.info/Scribus/trunk/Scribus
$ cd Scribus
$ cmake -DCMAKE_INSTALL_PREFIX:PATH=~/aplic/scribus_135

I obtained an error during the compilation because I didn't have "libqt4-devel" so:

$ zypper install libqt4-devel


:::bash
$ make
$ make install
$ ~/aplic/scribus_135/bin/scribus

Here are two screenshots, the main window and scribus latex editor:

That's all.

References:

• http://wiki.scribus.net/index.php/Building_SVN_versions_with_CMake
• http://scribus.info/svn/Scribus/trunk/Scribus/README
• http://wiki.scribus.net/index.php/Working_with_latex_frames
• http://wiki.scribus.net/index.php/Embedding_other_external_tools_into_a_TeX_frame

After this blog has been dead for about two years, I will start with some technical stuff – at least when computers don’t work as expected, most times I know how to fix it.

Ok, lets move on to the topic of this post. Short time ago I was forced to do some stuff on windows again (EEKK — the word registration number still sends me cold shivers …). As I needed really working USB support (unfortunately Nokia thinks Linux is good enough for their hardware, but not for their customers computers), and I was unable to make it work neither in Xen (not at all) nor with KVM (unusably slow), I ended up with VMWare.

So, USB worked really nice, no problems at all. While I was there, I thought „let’s have a look at the 3D acceleration“. At a first glance, it looked quite easy – „upgraded“ the VMs version to 6.5, and ticked the option for „3D acceleration“ – TADA – „Failed to construct 3-D rendering backend. The 3-D features of the display card will be disabled.“

Ok, what’s wrong? After some digging in the log, I found these two suspicious lines:
mks| GLUtil_InstallExtensionLists: Missing required extension GL_EXT_texture_compression_s3tc
mks| GLUtil_InstallExtensionLists: Missing required extension GL_EXT_framebuffer_object
Unfortunately, the Intel driver does not support these two OpenGL extensions – more or less.

Let’s have a deeper look into this. First, S3 texture compression. S3TC is a lossy texture compression used in many games, and it is mandatory for DirectX. Unfortunately, S3TC is covered by some patents, and although the decompression is handled by the hardware, a conformant OpenGL driver has to handle decompression and compression. As in many cases (most games ship with precompressed textures) only decompression is needed, which is handled by the hardware, there is a switch to force Mesa to report support of S3TC although it actually only handles one half – if you want to know more, force_s3tc_enable drirc are the keywords.

If you want to know more, or even want to enable compression as well, have a look at Roland Scheideggers‘ page.
As said, S3TC is covered by patents, so enabling compression is legally problematic. But there may be some hope, as S3TC is „owned“ by VIA, and they recently open sourced their Linux graphics driver, maybe we will even get S3TC out of that – at least, they could put compression under a liberal license, and still sell licenses to ATI/Nvidia/Intel (I still may have some dreams, don’t I?)

The other part is GL_EXT_framebuffer_object, shortly referred to as FBOs. These are really not supported by the Intel driver at the moment, but there the new memory managers come to the rescue, see this post.

Summarized, as soon as GEM has landed in the kernel tree (and/or in the downstream distributions), it should be possible to make it work. GEM should be available soon, and S3TC can be worked around today.