Older blog entries for Zaitcev (starting at number 418)

RSPoD on Rawhide

The Penny-Arcade game a.k.a. RSPoD is out today and it bombs on me with: "Could not find a compatible display device // Make sure your display device supports OpenGL 1.2 and the following extensions: ARB_multitexture ... ARB_texture_compression EXT_texture_compression_s3tc". On my system, OpenGL is provided by MESA 7.1-0.29.fc9, and according to glxinfo, some required extensions are missing. That wouldn't be so bad, but I have no idea what how this may be corrected. Hardware OpenGL in the video card, I guess. I have "Radeon Xpress 1100 IGP", which is a low-end mobile card.

UPDATE: Received the following e-mail:

Hi I had the same problem on Vista, because on my laptop the latest installed drivers were the ones I got from windows update. I then installed the ones that came from the manufacturers site and voilà..

. . .

UPDATE: See Anholt's entry.

Syndicated 2008-05-22 00:22:48 (Updated 2008-05-23 04:16:21) from Pete Zaitcev

Rio and Upstart

Seen at Rio's place:

Fedora9のupstart、すごいんですけど...。さすがに組み込みみたいな速さでは無いけれど、これならサスペンドしなくても良いんじゃ...。

Which, in my very approximate translation means:

Upstart of Fedora 9 is great, mostly. As expected it includes no visible speed, so not using suspend is not good.

So, I guess that Rio expected improvements which would allow to stop suspending and they did not materialize... Which makes sense, but why the superlatives then? The title of the post was "upstartすげい！" with the exclamation mark. I would understand if he wrote that Upstart allowed him to end suspends, but no, "速さでない" is simple enough even for me to understand. Oh well, perils of international blogging.

Once I figured out that the control file syntax is documented in events(5) of all places, Upstart became rather tolerable, even welcome. I think that our famously poor bootstrap times (which are not that bad in Fedora when compared to other distros — I've seen real hard benchmarks — but are just bad for me as a user) have more to do with trying to execute too much crap. Upstart allows us to do it more efficiently, but it's a palliative.

UPDATE: piyokun comments that the right translation is more like "Of course it's not as fast as embedded (linux), but with (upstart) you can get by without suspending." So, the "shinakute" is like "doing", "mo" is change of state (he suspended before, but not anymore), "n" is explanation tag, and "ja" is uncertainty. Casual, of course. Oh, and "kumikomu" is a verb meaning "to incorporate". I had no idea that they had a native word for "embedded", instead of a katakanized borrowed word.

Syndicated 2008-05-14 07:35:27 (Updated 2008-05-14 17:48:31) from Pete Zaitcev

John Carmack and Linux VT

Says John:

Our flight computer now has a display screen to show the current status to a pilot. My first inclination was just to mmap the framebuffer and pretend I was back in the days of DOS, but I decided to try and be a good linux programmer and use ncurses. It took me longer than I expected to get it working properly for displaying on the VGA for an application launched from a telnet session, and the performance was very bad. I wound up writing directly to the terminal device myself, spitting out all the escape sequences manually, but it was still quite appallingly slow. I have it working acceptably by only updating the various display items in a scanning fashion to avoid slowing it down on any individual frame, but I should have just followed my first thought and gone with a direct memory mapping.

I'm a little disturbed by the above, because I consider his application essentially equivalent to what Hercules does, and I never saw any performance issues with it. We all know that ncurses is a pig, and of course he should be using Slang instead of ncurses, but since he says that the result was slow even for the raw sequences, certainly this is not the issue. Weird.

It would be awesome if he posted his code somewhere.

UPDATE: John replies in comments:

The flight computer is only a 486-100, so it doesn't take much to bog it down, even with just text writes. I am doing straightforward fwrites and fprintfs to the console tty for everything.

It is at an acceptable rate now, so I probably won't make any other changes, but if RRL decides that they want anything fancy, like scrolling bar graphs, I will go straight to the framebuffer.

Syndicated 2008-05-13 01:25:22 (Updated 2008-05-13 20:14:59) from Pete Zaitcev

BadName is essentially conquered

The issue with random applications failing to start (Firefox, Nautilus) or blowing up (panel, gvim) with BadName took me about 3 months to find (the bug was filed at the end of January). I'm not sure if my fix is any good, need to poke Ajax about it.

So... Wasted a lot of time, learned several mildly interesting things about the code and people involved.

The sad part is how much it takes to start moving around any modern codebase, and that's with the same language and toolchain. I remember times when no part of the system was off-limits, but these days... not so much. If anything breaks in OpenOffice, I'm not even going to try fixing it.

Syndicated 2008-05-02 10:23:00 (Updated 2008-05-02 10:24:01) from Pete Zaitcev

Ted Tytso on [Open]Solaris

Ted suddenly decided to talk OpenSolaris. Pretty interesting... at least for me, since I spent 7 best years of my life in Sun's orbit.

In passing, aside from the bulk of the post, it seems to me that the final argument, about competitors selling Solaris support, does not hold water. This is exactly what Oracle attempted with their clone of CentOS and they weren't very successful, despite having a strong Linux team under Wim.

Other than that, he's probably right. But he's going to get responses. Whenever I mention Solaris (last time it was when I linked to Jeff Bonwick's blog), I get the most inane responses from Solaris fanboys. It looks like a very vocal community of users, if not contributors. Sounds like Apple almost.

This puts the damper on any dreams I may have about re-living the glory of my youth by getting back to hacking on that codebase.

UPDATE: Not sure why Levon decided to post his reply to his personal blog instead the one at Sun. Surely the other one is more relevant?

Syndicated 2008-04-23 18:12:46 (Updated 2008-04-23 20:38:59) from Pete Zaitcev

Random dmesg errors

I always was against kernel spewing user-generated errors into dmesg, like this:

npviewer.bin[4393]: segfault at f6712030 ip 67e7a0 sp ff9c39ec error 4 in libpthread-2.8.so[677000+15000]

Not helpful, not interesting.

However, the other day my desktop keeled over in a strange way... The /var/log/messages contained this (followed by a stack trace):

Apr 13 18:19:14 niphredil kernel: Xorg: page allocation failure. order:3, mode:0x4020

It looks like a bug in SLUB (does not seem registering with anyone who has the power to track it down though). But my point is, without the printout I would need to find what was happening by other means, and that would probably take forever.

Hmm... My world is shaken.

P.S. kgdb was merged into 2.6.26. The sky is falling.

Syndicated 2008-04-19 19:29:06 from Pete Zaitcev

Jon Corbet on Red Hat and Desktop

Seen at LWN today (no permalink — what the heck?):

Red Hat's desktop team has posted an item saying that the company has no plans to offer a "traditional desktop product" anytime soon.

Say what? The referenced item says:

[W]e have no plans to create a traditional desktop product for the consumer market in the foreseeable future.

Umm... RHEL desktop is doing quite well, all we're saying we're not committed to selling it at Best Buy. Not sure how this debacle has happened. Jon was probably short on coffee.

Syndicated 2008-04-17 17:28:04 from Pete Zaitcev

ipv6.google.com

If client is logged in, Google bounces to the old site. In order to access over IPv6, you have to log out and use http://ipv6.google.com/webhp. Apparently, not quite there yet.

One funny thing, using Google while logged out is much faster. Apparently it takes time for them to act upon cookies my client sends. Remind me again how they goaded everyone into this "homepage" thing. Ah yes, Gmail.

Syndicated 2008-04-16 16:30:45 from Pete Zaitcev

Fallback-induced thoughts

I saw two or three bug filings in last couple of months which deal with a USB device not working until ehci_hcd is unloaded. Thinking sensibly, it's rather normal, a poorly-made or poorly-cabled device may choose to report High (480) speed yet will be unable to communicate at that speed. And a couple of devices failing across half a million of users is rare. However, the thing is, such cases were extremely rare before, I don't even remember the last time this happened. So, I'm starting to worry that EHCI hardware or software may have a subtle bug somewhere (perhaps specific silicon percolated to the field).

If only there was a way to tap into Novell's bugzilla and watch their kernel bugs, to collate with ours. Ditto the Bligh's Bugme and Ubuntu's whatever (Launchpad?).

For readily identifiable bugs, we just report them to linux-usb or whatever and then patterns just come together, but the problem of fallback-wannabe devices is too flimsy and vague.

P.S. By "fallback" I mean the new code which switches a port over to a Full (12) speed if enumeration fails. It's a practical solution, but it seems like sweeping the problem under the carpet to me. Also, it won't work for anything that's plugged into a hub.

UPDATE: Amit from Ubuntu pointed to their bug 88746. V.interesting.

Syndicated 2008-04-15 21:29:40 (Updated 2008-04-16 01:47:52) from Pete Zaitcev

Unpleasant mass updates

Mass updates to Bugzilla have a few unpleasant side effects:

• Unless they're done by DKL with direct access to the database, they generate a lot of e-mail which buries actual updates.
• They destroy the usability of queries for "bugs modified in the last 60/45/30 days". It's a useful trick I learned from Arjan. But now all kernel bugs are recently modified.

The idea, I guess, is that developer has to rescan relevant bugs and either work on them, push them into NEEDINFO, or close them. If hackers are dilligent about it, auto-closer is harmless [and also, unnecessary -- ed]. In reality though, it just does not work that way [and the very existence of auto-closer is the proof -- ed]. At certain point, I started making extra-Bugzilla lists of bugs which look realistic to work on (e.g. have an active submitter who cooperates, for one thing). The rest just rots. I don't even have cycles to push WONTFIX on them (or, actually, I have time to close, but I don't want to deal with the fallout, so I just pretend not to see them -- the task made easier by the mass-update and the resulting mail avalanche).

P.S. My list of bugs is, like, 10 to 50 times smaller than Chuck's and DaveJ's. I don't understand how they cope. It seems impossible to me, so there must be some trade secret good kernel monkeys know.

Syndicated 2008-04-14 22:45:03 (Updated 2008-04-14 22:46:34) from Pete Zaitcev