listing init scripts, sorted by priority on RedHat

If you want to know in which order RedHat will execute init scripts, then you can list them like this:

grep '#\s*chkconfig:' /etc/init.d/* | sed 's/:#//; s/\/etc\/init.d\///;' | awk '{ printf "%2s %2s %7s %s\n", $4, $5, $3, $1 }' | sort

which will produce on my system:

01 99   12345 sysstat                                                                                                                                     
02 99   12345 lvm2-monitor                                                                                                                                
03 97     235 sysstat                                                                                                                                     
05 95     345 kudzu                                                                                                                                       
06 99   12345 cpuspeed                                                                                                                                    
08 92    2345 ip6tables                                                                                                                                   
08 92    2345 iptables                                                                                                                                    
 0 99    2345 microcode_ctl                                                                                                                               
10 90    2345 network                                                                                                                                     
11 88    2345 auditd                                                                                                                                      
11 89       - netplugd                                                                                                                                    
12 87    2345 restorecond                                                                                                                                 
12 88    2345 syslog
13  1     345 setroubleshoot
13 87    2345 irqbalance
13 87    2345 mcstrans
13 87     345 portmap
13 87       - multipathd
14 86     345 nfslock
15 85    2345 mdmonitor
15 85       - mdmpd
18 85     345 rpcidmapd
19 69       - rpcsvcgssd
19 85     345 rpcgssd
20 80       - kdump
22 85     345 messagebus
25 75     345 netfs
25 88    2345 pcscd
27 73       - ypbind
28 72     345 autofs
30 74       - nscd
35 65       - krb524
41 89       - rdisc
 4 99    2345 readahead_early
50 50       - netconsole
55 25    2345 sshd
56 50     345 xinetd
58 74       - ntpd
60 20       - nfs
64 36       - mysqld
80 30    2345 sendmail
85 15    2345 gpm
85 15       - httpd
90 10    2345 xfs
90 10       - psacct
90 60    2345 crond
91 35       - smb
91 35       - winbind
95 05    2345 anacron
95 05       - saslauthd
95  5     345 atd
95  5       - conman
96 99       5 readahead_later
97 03     345 rhnsd
97 03     345 yum-updatesd
98 02     345 avahi-daemon
98 02     345 haldaemon
98 02       - avahi-dnsconfd
99 01    2345 smartd
99 95      35 firstboot

Tomáš Pospíšek

Creating a shaded relief map from digital elevation data is a nice way to create a backround map for web mapping or other GIS work. Thanks to the know-how and the funding from the Swiss Humanitarian Aid Unit, QGIS now has a sophisticated function for relief map generation. The method is described in detail in an paper by Marc-André Bünzli. An important part of the method is the choice of the elevation colors. The QGIS plugin has the possibility to analyse the frequency distribution of the elevation values in the DEM and to propose color changes where significant changes in the histogram occure. It is of course also possible to modify the color scheme, to insert a completely different one in the dialog or to generat a shaded maps without color.

As illustrated below, the relief map is composed by three components modulated onto the final map to give it a more three-dimensional appearance. These intermediate steps are shown here to get a better understanding of the method. In QGIS, the user directly gets the combination as a result.

• The first component consists of a hillshade from north-west (300 degree) and an elevation color

• The second component is a hillshade and a gray value depending on the slope angle (darker is steeper). The hillshade angle of this second component differs to the first component by 15% to have better contrast in faces towards the light source. The second component is merged to the relief map with 30% weight.

• The third component consists of a hillshade from 270 degree and a yellow color in cells facing towards the light source. It is merged to the relief map with 10% weight

And the final relief map looks like this:

QGIS already offers a lot of possibilities to visualize raster data (contrast enhancement, color map, handling of transparent pixels, …) Last year, Radim Blazek refactored the raster provider interface and added on-the-fly reprojection support for rasters to QGIS. Very cool!

One of the few things currently missing in QGIS raster layer is the possibility to have other resampling types than nearest neighbour. The problem is that rasters appear pixelated when zooming further than the source raster resolution. So for applications like web mapping, it is important to interpolate the pixel colors and to have a broader display scale range for layers. In the last few weeks, I’ve added bilinear and cubic raster resampling to QGIS (thanks to Canton Solothurn for funding these activities!).

A lot of refactoring was necessary in the raster layer code to add resampling in a clean way. Therefore these changes are available in branch ‘raster_resampler’ of the QGIS github clone (git://github.com/mhugent/Quantum-GIS.git). It probably needs a longer period of testing to make sure every feature of the raster layer class still works properly.

The resampling option can be chosen in the raster properties dialog:

And here is the effect for a three band color image.

Nearest neighbour:

Bilinear:

Cubic:

And here for a palletted background map

Nearest neighbour:

Bilinear:

One would expect that considered the complexity of gdm there would be a way to have per user X11 options. So no, there isn’t one. At least not after the great rewrite after V2.22.

However good old Unix paradigms can help us (this is all under Debian, other Unices will allow a similar trick):

$ vim /usr/local/bin/X

Add something similar like this:

#!/bin/sh
#
# start X with different options depending on user

# check if the parent gdm process that started us contains
# "--username le_gamer" in its commandline
#
if ps -p $PPID -o args= | grep -q 'username le_gamer';
then
  exec /etc/X11/X.orig $* -config /etc/X11/xorg.conf.le_gamer
else
  exec /etc/X11/X.orig $*
fi

We check whether gdm is starting us and using the parameter “–username le_gamer”. If it is, then we’re using a different config file for X.

Of course you’ll need to adapt all this, unless you are using Debian or Ubuntu. You need to adapt the path to the X Server, to the config files etc.

Why did I do that? The problem is that Intel’s X server in Ubuntu Lucid Lynx 10.04 is really unstable with DRI on a Intel GM965/GL960 graphics card.

So unless I’m playing 3D games which are a lot faster with DRI, I don’t want to enable DRI (more over, “NoDRI” is pulling less power out of my battery). So my normal config contains this:

$ cat /etc/X11/xorg.conf
[...]
Section "Device"
        Identifier      "Configured Video Device"
        Option          "NoDRI"
EndSection

So now, the only thing you need to do is replace your “normal” X Server with the new “adaptable” one:

$ sudo mv /etc/X11/X /etc/X11/X.orig
$ ln -s /usr/local/bin/X /etc/X11/X

That’s it,

Tomáš Pospíšek

SVG markers are a popular way to symbolise points in QGIS. Predefined markers are available in $PREFIX/share/qgis/svg and it is straightforward to add new symbols or to create own symbols with a vector graphics program (e.g. Inkscape). A disadvantage so far was the need to create different versions of an svg file to have the same symbol in several colors. A recent change in QGIS now introduces the possibility to insert parameter tags into the svg file and QGIS is going to replace them with the values for fill color, outline color and outline width.

It works with a syntax similar to the svg params working draft. Let’s say we have the following simple svg file:

<svg width="100%" height="100%">
<rect fill="#ff0000" stroke="#00ff00" stroke-width="10" width="100" height="100">
</rect>
</svg>

To have the possibility to change the colors of the marker, we have to add the placeholders ‘param(fill)’ for fill color, ‘param(outline)’ for outline color and ‘param(outline-width)’ for stroke width. These placeholders can optionally be followed by a default value:

<svg width="100%" height="100%">
<rect fill="param(fill) #ff0000" stroke="param(outline) #00ff00" stroke-width="param(stroke-width) 10" width="100" height="100">
</rect>
</svg>

Now it is possible to change fill color, outline color and stroke width using the new elements in the QGIS symbol layer dialog.

Replacing parameters and rendering svg can be expensive in terms of processing time. Therefore, an svg cache has been added which accelerates painting of svg markers considerably. For drawing on screen and with QGIS server, the svg markers are painted as rasters. For printing, a vectorized output is generated.

This work was funded by the Canton of Solothurn (Switzerland). Thank you very much!