Morten Welinder

xorg-redhat-die-ugly-pattern-die-die-die.patch is a perfect example
of a bad we-know-better attitude.

It removes the beautiful grey cross hatch stipple from X. Evidently
because someone knows better what other people like. How does one
get it back, short of tiling a bitmap? If it is anything like
SuSE’s similar patch, you don’t. At least not while the X server
is running.

In summary. Before: you could have a solid-colour background or you
could have a cross hatch background. Just you xsetroot.

After: you get what some monkey with poor eyesight though looked
nice. You cannot change it. After all, he knows better.

Incidentally, the default X pattern also serves to show the poor
state of flatscreen technology. It seems the pattern cannot be
shown over the whole screen without a certain amount of flicker.

DTrace looks nice, but it is not as-if the means to do what it does
haven’t been along for a long time.

My humble contribution: strace-account.
To use…

strace -o ~/ttt top
# q when you get tired
strace-account ~/ttt | less

from which we learn:

Cumulative Syscall Times.
------------------------

Syscall  Count  Time(s)
-----------------------
select       8    19.42
read      3939     0.06
open      3165     0.04
close     3172     0.03
alarm     2142     0.02
stat      1565     0.02
fcntl     1523     0.01
(other)    336     0.01

Repetitive File Name Usage.
--------------------------

This is a list of files that are accessed, one way or another, at least
twice.  Note, that current directory is not being tracked.

Count  Filename                   
----------------------------------
   14  /var/run/utmp
    8  /proc
    8  /proc/1
    8  /proc/1/stat
    8  /proc/1/statm
...
    2  /proc/meminfo
    2  /proc/stat
    2  /usr/share/terminfo/x/xterm

Small-Chunk File Input/Output.
-----------------------------

This is a list of files that are accessed in small chunks.  "Badness" is a
heuristic measure of this.  The list is truncated at badness 2.00.  A file
can appear more than once if it is opened more than once.

Badness  Bytes  I/Os  File                       
-------------------------------------------------
  12.75  38784   102  /var/run/utmp
  12.75  38784   102  /var/run/utmp
  12.75  38784   102  /var/run/utmp
  12.75  38784   102  /var/run/utmp
  12.75  38784   102  /var/run/utmp
  12.75  38784   102  /var/run/utmp
  12.75  38784   102  /var/run/utmp
   2.67   2122     8  /usr/share/terminfo/x/xterm
   2.26  40878    23  (stdout)
...

My interpretation of this version of top’s output is that it is
opening way too many files way too many times. why is it also
calling stat(2), alarm(2), and fcntl(2) so often? [So it can connect
to /var/run/nscd/socket in non-blocking mode over and over again, if
you must know.] It also likes to read utmp many, many times in little
pieces.

(strace-account is a bit of a hack. An strace with an output format
more suited for machine reading would be nice. It might even have
appeared since whenever I wrote strace-account.)

Both GTK+ and Gnome promise ABI and API stability.

But what does that mean?

To me it means that updating API/ABI stable libraries should not
break existing applications. This should not keep one from fixing
bugs — if you depend on those you get what you deserve — but
existing, well-defined, well-documented interfaces ought to continue working as previous.

The recent updating-glib-breaks-pango issue could, with a little good will, be considered a case of a
bug in old pango that now have triggered.

But what about the new updating-gtk+-breaks-stuff issue? Evidently soneone though it would be nice to change the basic ways reference counts are handled for GTK+ objects. That causes leaks, and leaks for widgets can mean they stay visible when they should not have been, i.e., applications are now broken. This is not right!

There is some talk about fixing the GTK_OBJECT_SET_FLAGS macro (and presumably the GTK_OBJECT_FLOATING macro) to plaster over the issue and regain some amount of API compatibility. The ABIs would remain incompatible,
so someone updating their libraries would still see their
applications break and come to me.

What can I as an application programmer do about this?

• Demand that the GTK+ changes be rolled back. That would be the right
  thing to do and is a very reasonable demand. They could go back in for GTK+ 3.
• Throw in some “incompatible with GTK+ 2.9 and later” dependency
  and get it deployed. Awful, right? Deployment is a multi-year
  effort.
• Rush in some devious works-both-places code and get that
  deployed. Marginally less awful, but still suffers from the deployment delay.

Incidentally, it is not at all clear what tangible benefit there
is to the changed reference count scheme. I am all ears.

There is a burst of activity in the GTK+ theme world these days.
How do I know? Well, I get bugs like this for Gnumeric. This was a debug build with a reporter
that took the time (and had the knowledge) to tell us that a theme was involved, so it was pretty easy to diagnose as Someone Else’s Problem.
But when it happens with some distribution’s theme, it generally
requires a crystal ball.

In my humble opinion, something is wrong with the way themes are
done in GTK+. The current situation is:

• When a theme engine crashes, the blame is placed on the application by both the user and Bug Buddy.
• There is no fault-separation between the application and the theme. Theme engines are written in a fault-intolerant language.
• Theme code is written by people more interested in visual effects than code. The code receives less scrutiny than, say, GTK+’s main code.
• Application developers cannot test with themes they do not know.

Ideas?

Week numbers are not used in the US who it is pointless to start
thinking about how weeks might be numbered there. I do not know
if week numbers are in use in Asia, but I do not think so.

That leaves Europe[*] and the name of the game is ISO 8601 and The Right
Answer[tm] therefore is:

Week number of 24/12/2005: 51
Week number of 25/12/2005: 51
Week number of 26/12/2005: 52
Week number of 27/12/2005: 52
Week number of 28/12/2005: 52
Week number of 29/12/2005: 52
Week number of 30/12/2005: 52
Week number of 31/12/2005: 52
Week number of 1/1/2006: 52
Week number of 2/1/2006: 1
Week number of 3/1/2006: 1
Week number of 4/1/2006: 1
Week number of 5/1/2006: 1
Week number of 6/1/2006: 1
Week number of 7/1/2006: 1

as dumped by

static void
dump (int d, int m, int y)
{
	GDate *gd = g_date_new ();
	g_date_set_dmy (gd, d, m, y);
	printf ("Week number of %d/%d/%d: %d\n",
		d, m, y,
		g_date_get_iso8601_week_of_year (gd));
	g_date_free (gd);
}

So there you have it: all weeks are seven days long (what a concept!)
and go from Monday to Sunday. The first week of 2006 starts on the second day of January 2006.

[*] Thus assuming that no-one in Africa, for example, has been
stupid
enough to invent their own date magic for no good reason.

Do not bother.

No, really. That function, regardless of implementation, basically
screams “if you call me often, your program will exhibit quadratic
or worse time behaviour, so do not do that.”

It is fine for occasional use, but then you would not care about its
efficiency.