Today - well, most of the work has been done in the last few hours which would mean yesterday as well - I finished the newest unofficial mtx driver version, v1.4.4.3.

The main reason for the new driver version was a posting in the Matrox General Linux Support Forum where a user mentioned, that the current unofficial driver version doesn't compile on 2.6.19-rc3 anymore.
The reason for this simply was that the kernel developers finally got rid of <linux/config.h> in favour of <linux/autoconf.h>. Due to the fact that I had some time yesterday, I fixed some other stuff in the q'n'd 1.4.4.2a release.

ChangeLog:
  * Fixed a typo in an informational output string
  * Fixed a warning during the compile process
  * Fixed the issue with GFP_DMA32 that prevented 1.4.4.2a to build on kernels prior to 2.6.18
  * Fixed the above mentioned issue with 2.6.19-rc3
  * Renamed the installer package according to the new naming scheme introduced by the first
    unofficial mga driver

Still not fixed is the new installer promised for 1.4.4.3, but maybe it will be part of 1.4.4.4...

Downloads:

• matroxdriver_mtx-x86_32-1.4.4.3-installer.run (32bit)
• matroxdriver_mtx-x86_64-1.4.4.3-installer.run (64bit)

Yesterday I finished a new website project. This blog entry is - as usual - only for feeding google. Links: http://www.skiverleihdie2.at

Today I finally found the time to repackage the official mga drivers. The new unofficial driver series (v4.4.1) differs from the official version in the following few things:

ChangeLog:
  * Added support for Xorg 7.1 and 7.1.1
  * Introducing the updated-installer from David E. Anderson
  * Put the tarball into a nice installer known from the mtx drivers

Downloads:

• matroxdriver_mga-x86_32-4.4.1-installer.run (32bit)
• matroxdriver_mga-x86_64-4.4.1-installer.run (64bit)

Limitations:
When installing these drivers for Xorg 7.1* you still need to add the following section to your "/etc/X11/xorg.conf":

Section "ServerFlags"
  Option "IgnoreABI" "True"
EndSection

Yesterday I ordered a La Fonera and signed up to be a part of the Fon community. In about two or three weeks, my La Fonera will arrive and I'll have a look if its functionality does fit my needs. The key features are: Linksys Accesspoint for free (at the moment, so act quickly!) 2 SSIDs configured (one open for all, one for private use) Full traffic shaping management and full control about the amount of traffic that you provide for other Foneros Open Source Firmware Firmware updates on a regular basis ... In two to three weeks I will know more details about this whole topic. If you are interested in this idea, come and join us and put your flag on the fon maps.

Yesterday I received a mail from my brother telling me, that my explanation of a child process is wrong in some points. He claims that a child in general has more in common with a thread. Just read his explanations and tell me, what you think of it:

1. What about ressources? A child-process in this context uses a lot of
   the parents ressources and is therefore running in the same memoryspace
   as the parent does.
2. A child process is created by two parent processes. Normally. 
3. In the first few month the communication between parent and child
   is often disturbed by interferences, so only a heuristic-based
   communication can be established to process the childs I/O.
4. Most child processes develop a certain affinity for distance after a
   specific runtime and begin to become parents themselves caused
   by an own memoryspace.

So, the only suitable explanation can be as follows:

In reality it is not a child process, but a thread (see 1), which is created
because of inconsistence in the process communication between the parents
and starts to bed in a designated parent process (see 2). If a certain runtime
has passed, the thread becomes more and more resource-hungry so that
a separate process is started, which inherits all the properties of the former
thread. Due to the lack of documentation, the communication between the
three processes has to be defined at runtime, which normally lasts a few
month (see 3). If everything has developed as planed, the childs database
grew in a way, that the restrictive policy of the parents is no longer acceptable
(see 4).

Thanks to my brother Markus for bringing my attention to these issues.

I promise: The next time I'll do my homework before blogging

Yesterday, my new Matrox Parhelia APVe arrived which allowed me to finally set up my new Dell Optiplex GX620.

After hours of copying my tons of gigabytes of data to the new machine and building a new custom kernel it booted well and let me re-install the driver for the APVe (which should be the same as for the Millenium P750).

I'm now running a dualcore system with 2GiB of RAM, Triplehead powered by the Matrox Parhelia APVe and 1155fps in glxgears (the Millenium P750 had only about 600fps on my old system).

Being that fascinated of the newly acquired power under my desk, productivity increased dramatically today

I fork()'ed again.
For all of you who don't know what fork() is: It is a system call.
Here's a short quote out of the manual page of fork() plus some explanations of what they mean in real life:

FORK(P)                    POSIX Programmer's Manual                   FORK(P)

NAME
       fork - create a new process

SYNOPSIS
       #include <unistd.h>

       pid_t fork(void);

DESCRIPTION
       The  fork() function shall create a new process. The new process (child
       process) shall be an exact copy of the calling process (parent process)
       except as detailed below:

This far, everything should be clear. At least one parent process creates a child process. In real life, a child process looks something like this:



Per definition, a child process differs in some points from the parent processes. The details are explained below:

        * The child process shall have a unique process ID.

This can be accomplished by giving the child process its own name, e.g. if your name is Sepp, don't call your child process Sepp too.

        * The  child  process ID also shall not match any active process group
          ID.

Don't call it like any group you know, e.g. colleagues, neighbors, ...

        * The child process shall have a different parent  process  ID,  which
          shall be the process ID of the calling process.

This one translates to the surname and usually can be realized easily.

        * The  child  process  shall  have  its  own copy of the parent's file
          descriptors.  Each of the child's file descriptors  shall  refer  to
          the  same open file description with the corresponding file descrip-
          tor of the parent.

Give your child process a separate room in your house/flat/whatever but make sure that its newly created room is accessible from your own rooms.

        * The  child  process  shall have its own copy of the parent's message
          catalog descriptors.

Teach him/her your language. This may take a while but is usually very effective later on.

        * The  time  left  until an alarm clock signal shall be reset to zero,
          and the alarm, if any, shall be canceled; see alarm() .

Don't use alarm clocks near your child process rooms otherwise you won't have recreative nights anymore.

        * File locks set by the parent process shall not be inherited  by  the
          child process.

It's in the nature of a child process to disobey your rules and to not pay attention to forbidden items and locations so don't blame it for doing thinks like that.

        * The  set  of signals pending for the child process shall be initial-
          ized to the empty set.

Well, that's clear, it can't process it anyway the first few weeks.

        * No asynchronous input or asynchronous  output  operations  shall  be
          inherited by the child process.

Child processes tend to do all things simultaneously anyway, so asynchronous input or output is not available in the first few years...


I hope you all un-fork()'ed guys out there now realize what it really means to fork ;)
BTW: The main purpose of this blog entry was to present some pictures of our newest unborn child process.

Click here to enter the gallery