Older blog entries for Zaitcev (starting at number 397)

Today, I hate... who?

Not sure who to hate today. At first I was going to hate Karsten, but I quickly realized that he's actually on the good side, fixing problems rather than causing them. But someone has to be responsible for the abomination known as libtool, right?

It all started when I wanted to run Hercules. I extracted my old images and hercules.cnf, ran "yum install hercules", and then... Hercules starts, but recognizes no devices, starting with the 3505.

The problem is in the so-called "dynamic load": emulators for devices are shared objects, and our stock Hercules on Fedora searches for them everywhere except where necessary:

  write(4, "HHCCF065I Hercules: tid=2AD76E5C"..., 72) = 72
open("/hercules/hdt3505.la", O_RDONLY)  = -1 ENOENT
open("/hercules/hdt3505", O_RDONLY)     = -1 ENOENT
open("/lib/hdt3505.la", O_RDONLY)       = -1 ENOENT
open("/usr/lib/hdt3505.la", O_RDONLY)   = -1 ENOENT
open("hdt3505.la", O_RDONLY)            = -1 ENOENT
access("/lib/hdt3505", R_OK)            = -1 ENOENT
access("/usr/lib/hdt3505", R_OK)        = -1 ENOENT
open("/etc/ld.so.cache", O_RDONLY)      = 10
fstat(10, {st_mode=S_IFREG|0644, st_size=84779, ...}) = 0
mmap(NULL, 84779, PROT_READ, MAP_PRIVATE, 10, 0) = 0x2aaaaf55b000
close(10)                               = 0
open("/lib64/tls/hdt3505", O_RDONLY)    = -1 ENOENT
open("/lib64/hdt3505", O_RDONLY)        = -1 ENOENT
open("/usr/lib64/tls/hdt3505", O_RDONLY) = -1 ENOENT
open("/usr/lib64/hdt3505", O_RDONLY)    = -1 ENOENT
munmap(0x2aaaaf55b000, 84779)           = 0
write(4, "HHCCF042E Device type 3505 not r"..., 42) = 42

The real path is /usr/lib64/hercules/hdt3505.so. Did nobody ever test?!

So I download the source, configure with --disable-dynamic-load, build, everything works. After all, the whole /usr/lib64/hercules is only 240KB, who needs dynamic modules anyway? Then, I want to be good and try to build an RPM... It bombs with "ld: undefined hdl_genhdl".

It gets even more involved. Apparently, when I run configure by hand, libtool fails, falls back to linking from .a, and then everything works. But when I build an RPM, libtool succeeds, produces .so, then linking fails because...

So, spent a day trying to understand how libtool worked and why removal of rpath causes it to produce garbage, etc. until it was time to sleep. Today, filed a bug, moved on. Let Matthias to puzzle it out.

UPDATE 20080103: Hans de Goede fixed it.

Syndicated 2008-01-29 21:42:38 (Updated 2008-02-03 19:57:30) from Pete Zaitcev

Liberal pie in the sky

Spot outlined a laundry list of things that our next saviour will do, which includes this:

* Obama will deploy a modern communications infrastructure.

Some people know how to dream big. One royal decree, and millions of workers in blue suits descend upon America; overnight a modern communications infrastructure (whatever that means) gets deployed, never to become obsolete thereafter.

UPDATE: As pointed in comments, the infrastructure item is a bracket, explained by other items on Spot's list [link]. The astroturfing machine mangled the message in transmission and produced the funny above.

Syndicated 2008-01-29 19:59:10 (Updated 2008-01-30 01:14:09) from Pete Zaitcev

Thank heavens, I'm not Japanese...

... because if I were, I'd have trouble with web services. Even now, in 2008, a disturbing number of them are unable to handle the basics of UTF-8.

For example, I have a tag "らき☆すた" at del.icio.us. Everything is fine... except the link "all", which comes up empty, although I know that the tag is used.

If you think that del.icio.us is only a pitiful Internet sitelet which is hardly representative, the mighty Google Reader says this in response to an innocous tag: ""愛より青し" is not a valid tag name. Only letters, numbers, underscores and dashes may be used." Yes, those " appear in the AJAX dialog in all their glory.

Kindle is only doing what everyone else is doing, it seems.

BTW, my position always was that everyone who touches a computer has to learn English. It's not that difficult and is required to communicate on the Internet. But being a hypocrite that I am, I demand solid support for UTF-8 from applications, and feel no cognitive dissonanse about it whatsoever.

Syndicated 2008-01-29 02:16:35 from Pete Zaitcev

Besieged by daemons

When I end my GNOME session in Rawhide, the following processes are left behind:

  USER       PID    VSZ   RSS STAT COMMAND
zaitcev   2122  19148  1036 Ss   /bin/dbus-daemon --fork ...
zaitcev   2152 171596  2900 S<   /usr/bin/pulseaudio --log-ta...
zaitcev   2187 168208  3860 S    /usr/libexec/gnome-vfs-daemon
zaitcev   2195  34864  1984 S    /usr/libexec/gvfsd
zaitcev   2206  43176  2172 S    /usr/libexec/gvfsd-trash --s...
zaitcev   6538 109260  4776 S    /usr/libexec/gconfd-2 13

Notice though, Gamin is not among them.

UPDATE: Colin says, quit blog whining and file a bug.

Syndicated 2008-01-27 07:00:34 (Updated 2008-01-27 20:28:29) from Pete Zaitcev

One year of FizzBuzz

FizzBuzz is an example of an interview question where the challenger is given a trivial problem with the objective to belt out a complete program.

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.

Most good programmers should be able to write out on paper a program which does this in a under a couple of minutes.

Want to know something scary ? - the majority of comp sci graduates can’t. I’ve also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution.

Something scarier for me personally is that it took me 5 minutes to do it. I don't know just who would be able to finish in 2 minutes. It looks like they are measuring the speed with which a person can write on paper instead of programming ability.

If they start asking this shit at interviews, my only hope is real estate or insurance.

P.S. English kids who play this game in kindergarten are freaking geniuses. The only sensible plan seems to be to keep two counters, which is actually quite challenging. I saw mental excersises like that, given in all seriouseness. For example, you read a long string of icons and count the number of ducks and airplanes in it, separately. Virtually nobody can keep track of 4 items together. The alternative for the kids is to sum numbers for a division by 3 really quickly. I don't know if kids are up to it.

Syndicated 2008-01-27 02:31:43 from Pete Zaitcev

GNOME is damn picky

UPDATE: The BadName below turned out to refer to a font name. My speculation about the DirectColor was bogus. GNOME is not picky!

I mentioned it in passing before, but did not elaborate. I have two identical Rawhide systems, a laptop and a desktop. Everything works dandy on the laptop, but a number of GNOME programs (including Firefox) abort immediately with "BadName (named color or font does not exist)" on the desktop. What could be different?

It looks like the diff of xdpyinfo(1) outputs has a clue:

  @@ -78,14 +79,7 @@
     red, green, blue masks:    0xff0000, 0xff00, 0xff
     significant bits in color specification:    8 bits
   visual:
-    visual id:    0x22
-    class:    DirectColor
-    depth:    24 planes
-    available colormap entries:    256 per subfield
-    red, green, blue masks:    0xff0000, 0xff00, 0xff
-    significant bits in color specification:    8 bits
-  visual:
-    visual id:    0x4a
+    visual id:    0x3a
     class:    TrueColor
     depth:    32 planes
     available colormap entries:    256 per subfield

The problem only started hapening after the libpciaccess thing, but it does not tell us if DirectColor existed in the previous X server or not. The libpciaccess rework caused a big gap in my updates, and possibly Cairo or GTK regression slipped into it. In fact, I seem to recall that Firefox worked on top of my patch for SiS, although I'm not sure.

Most of the GNOME continues to work, so it's not the same issues as the abandonment of 8-bit visuals, apparently.

I guess I'll just have to file a bug and see where it takes us, although... what component to use?

Syndicated 2008-01-27 01:42:28 (Updated 2008-04-23 21:49:48) from Pete Zaitcev

Seeing blue

Spot posted an ambiguous entry, which happened to coincide with some kind of Xft2 bug in Rawhide, which makes subpixel rendering to show colorful outlines of letters:

Peter Jones said in comments that the rainbows are not seen in screenshots, but of course they are. Look at the 'i' in Nigorimasen.

UPDATE: Just look at it with xmag already:

See that blue strip?

UPDATE: The subpixel rendering is actually off, the GNOME preferences are set for "best shapes". The problem is that they use colorful dots instead of grayscale ones. There must be some kind of reason why they decided to do it, and perhaps it is actually better on some CRTs. The fact is, everything looked fine until the last "yum update", and now it's hideous.

UPDATE: My word, they did it on purpose!

Syndicated 2008-01-23 18:12:40 (Updated 2008-01-24 20:01:22) from Pete Zaitcev

Today, I hate... Roland!

Actually, I don't really hate him, and he's not at fault, but I did waste a whole day on --build-id. I tried to build some kind of ancient Fedora kernel based on 2.6.21.7 for my own purposes, and it was bailing with: "ld: .tmp_vmlinux1: section `.text' can't be allocated in segment 0". The next line had the key to the problem, but it was too long and thus unreadable on terminal or in vi, and so I missed this: "LOAD: .note.gnu.build-id .text .text.rest_init [240 kilobytes on the single line follow] __param __bug_table". Killing the magic which added --build-id to LDFLAGS_vmlinux fixed the problem. But before that, I learned way more about vmlinux.lds than I ever wanted to know, and examined every object file in the kernel with objdump(1).

Syndicated 2008-01-22 23:53:56 from Pete Zaitcev

Jujumon

Since I'm on the blogging spree, I'm going to shed another dangling patch.

At OLS two years ago I talked about usbmon, and tried to persuade fellow hackers that it was a great idea and every subsystem should have one. Ergo, scsimon, firewiremon, infinibandmon. Well... two years down the road, and usbmon is the only one.

Actually not quite. When I tinkered with porting Kristian Hogsberg's Juju stack to RHEL 4 and did some other FW hackery in service of the Queen, I regretted many times that firewiremon (then renamed jujumon) did not exist. So I wrote it.

It was very useful for me personally, but unfortunately I was unable to make it upstreamable. Juju (or Firewire) needs way more intercept points than USB, so the hookage becomes unweildy, I was dissatisfied. Stefan Richter and Jay Fenlason would laugh me out of the mailing list if I posted that. Kristian has retired to GNOME by this time, or he'd laugh too. I moved to other things too, so I guess jujumon has to rot at my homepage for now. Dunno if I should be sad or what.

Syndicated 2008-01-22 08:07:32 (Updated 2008-01-22 08:09:24) from Pete Zaitcev

git, the person and the SCM

From Wincent (via apenwarr):

I knew Torvalds was smart, but seeing as I was never really more than an occasional Linux user I never realized just how smart; I'd thought he was just a good programmer who happened to be in the right place at the right time and had a few good ideas.

I learned it a few years ago, when Linux had a particularly thorny bug somewhere in its process management... Something was leaking on a process exit in case of some obscure error and nobody could figure it out. IIRC even Ingo took a stab and failed, and we all know that Ingo is excellent. Eventually Linus lost patience, went in for a day, fixed it. I had an Advogato diary at the time, but did not post anything, only made a mental note. Linus likes to pretend that he is just a project manager, but it's a sham.

BTW:

Git breaks the mould because it thinks about content, not files. It doesn't track renames, it tracks content. And it does so at a whole-tree level. This is a radical departure from most version control systems. It doesn't bother trying to store per-file histories; it instead stores the history at the tree level. When you perform a diff you are comparing two trees, not two files.

I wonder if X people (e.g. Keith) made a wrong move when they split their tree into a bunch of smaller git repositories instead of having one big repository like kernel does. I guess that it has to do with their phylosophy of being modular (remember, they have a stabe module API which kernel lacks), so they do not foresee code sharing (and thus movement) across their numerous modules and corresponding repositories. Maybe it reduces network traffic at their central git server.

Syndicated 2008-01-21 21:56:15 from Pete Zaitcev