Older blog entries for forrest (starting at number 77)

26 Mar 2004 (updated 26 Mar 2004 at 07:24 UTC) »

Which Linux Laptop?

At my work, I'm now doing some work on a java webapp written with Struts. Sadly, this means I'm now mostly using Windows ... even though everything I need to work on runs fine under Linux.

I have been using a Linux box at work that's a 200MHz or so cast-off, and have a kvm switch to go between it and my Windows box. Until this latest project, I've only used the Windows box for mail. Needless to say, it isn't quite up to the task of this java development. Even the 1GHz Windows box I have with 512 Mb RAM is clunky.

Although it really shouldn't matter what my desktop is, I'm struck by how clunky it is to do anything even a little complex without multiple virtual desktops. I'm always staring at the little rectangles (now almost squares) in the start bar, trying to deciper which of the many windows I have open is the one I'm looking for.

Although I doubt my work would spring for a decent Linux box for me, I think I could get a docking station if I brought my own laptop. Since I've wanted to get a linux laptop anyway, I've been thinking about that more and more.

The requirements are a little different than what I might choose on my own. A fast CPU, lots of RAM (at least a gig), and a big hard disk are what I need. Battery life is not a consideration in this case: I'll almost always be using this unit at work or at home, with external power.

All other things being equal, I prefer AMD CPUs, but that's just wanting to support the underdog, and is for me much less important than functionality.

I've always been initmidated to buy a laptop for running Linux; they're expensive and have all sorts of quirks which make it a gamble.

I'm soliciting recommendations, and I hope some of you will help me out before using Windows drives me (any more) batty.

Thanks for any advice!

You Rock!

Within minutes of my last post describing the gcc weirdness I was experiencing, tk put his finger on the basic problem: I was running into a stack size limit. And he gave me a workaround much simpler than my use of malloc.

Clueless as I am, I was still left wondering what had happened to my configuration, since my program worked back in August. AlanShutko provided the vital information: the stack size limit is a function of the shell. The ulimit -s command he suggested revealed that I do indeed have a stack size limit, set at 8192.

I can only guess this limit is compiled into the executable, because it's not in /etc/profile, ~/.bash_profile, or ~/.bashrc. My /bin/bash is dated Feb 22, so it has been replaced since my program last worked.

Finally, haruspex raises an interesting question: why wasn't the large unused array in my sample program simply optimized away? He tested this with gcc 2.95.4, and just now I tested with 3.3.3, and using -O2 doesn't get rid of the unused variable. This observation makes me feel "hey, this isn't just about me being an idiot". Cool.

Thanks, guys.

21 Mar 2004 (updated 21 Mar 2004 at 07:27 UTC) »
Debian "sid" gcc problem

I hate it when I get a problem with a basic piece of infrastructure and I don't know which piece is responsible for the error. Where does one begin to file a bug report?

Since this is my diary, I feel that I can at least blow off steam by posting here ... and maybe (often!) someone will give me a clue. That's got to be one of the most inefficient ways ever of filing a bug report, but hey ... it's just my diary, ok?

I run Debian "sid" (a.k.a. "unstable") and I was revisiting some code which worked on August 19th, only to have it segfault on me.

I eventually found I could reproduce the problem just by declaring a large array. Here is (literally) a hello world program which exhibits the problem on my machine:

#include <stdio.h>

int main() { /* char arr[8385040]; no problem */ char arr[8385041]; /* segfault! */ printf("Hello, World!\n"); }
The segfault occurs on the printf statement. WTF?

I get the problem when with either

 gcc -o hello hello.c && ./hello 
 gcc-2.95 -o hello hello.c && ./hello 

Can anyone else reproduce this, or am I just going crazy?

As a workaround, I found that I can use malloc to create my (syntactic equivalent to a) large array with no problem.

... random personal stuff ...

I just got back from my 4th trip to China. We're having trouble getting permission for my parents-in-law to visit the U.S. (the U.S. government objects, not the Chinese) and my mom really wanted to meet them. So we took her to Wuhan, and of course visited famous sites like the Great Wall while we were there.

I like China. I wouldn't want to live there, but I think it would be cool if I could work there for a year or so. I'm too tied to job security, though, to actually try to make that happen.

And oh yeah, Happy Birthday to me. I'm now 42 years old.

I never realized how hard (impossible) it was to even get a modestly complex html table to render correctly in modern browsers: I wrote an account of my frustrations (with screenshots) here.

Ok, I've got my perl script for price-shopping at CD BABY done. It adds the number of tracks as well as the prices to the genre list you select, and sorts it by price.

You still can't tell how long any of the CDs are, which is whack: number of tracks, although very poor, is the best clue available. (From now on, I'm writing the artists to ask how long their CDs are before I buy them!)

Find cdbaby_cheapskate.pl on my hacks page.

Java driving me nuts

I'm starting to get involved with a java development group at work, and I'm trying to get tomcat set up on my Debian box at home.

It's not going smoothly, and unfortunately no one has replied to my post to the debian-java mailing list, although it's been several days.

If someone here could offer me a clue, or advise me where else I should be asking, I'd be most grateful.

It seems that all my java experiences are going like this. It's not so much that it's a steep learning curve, it's that certain pieces of information I need are nowhere to be found.


I finally placed an order with the independant CD store that all the anti-RIAA slashdotters always mention. I talk about what I ordered over on LJ.

While they're really cool, I have two problems with their site

  1. They don't encourage price shopping, and
  2. They don't say how long any of their CDs are.
I wrote a little perl script to get around (1): it takes one of their "all artists of a given genre" html pages, fetches all the prices and outputs the html with the list sorted in price order, and with prices displayed. (I'll be putting it out on my hacks page once I get it a little more user-friendly.)

But shopping on price alone is not enough; the shortest CD I bought was 37:29 and the longest was 70:02 -- that's a huge difference. Duration isn't everything, but it's certainly an important factor.

I wrote to CD Baby asking them to include this information in their CD descriptions. I don't know how they'll respond, but if more people request the same thing (hint hint), I guess they're more likely to notice.

Athough I hope to blog free software related stuff here and keep my other stuff over at LJ, I just did a cool art thing, so I wanted to mention it here.

At least I used free and open source software ... perl to snarf webcam pics and mpeg_encode to make a timelapse movie.

6 Jan 2004 (updated 6 Jan 2004 at 03:22 UTC) »

Oh wow, responses about my gpg comment. Let me get replies in before it all leaves the recent log:

tmorgan: While I find the idea of somehow distinguishing between different levels of trust in the key infrastructure interesting, I think that would make it too complex for the non-technical user. Keeping it at "I trust this person not to send spam" is straightforward and has an obvious, big payoff for everyone involved (the spam problem is only getting worse).

I don't know to much about how it all works either, but I have read that some people have one key for signing and another (usually longer) key for encrypting. So perhaps one's signing key could be a spam trust key, and one's encrypting key could be a super-duper I rilly know you trust key. Mere mortals could be happy with the anti-spam key.

dyork: You're right, of course, about client support. I have been impressed enough with the usability of the Thunderbird/Enigmail combo to think that might be the app that will work for non-techies. (I've never tried gpg on Windows, though -- I'm just guessing things work similarly in that universe.) Home users have their choice of clients, and effective spamfighting might be enough of a draw to make people switch. Thunderbird is a typical GUI mail client; I think anyone could get used to it without much effort.

I know you don't have much choice about mail clients at work; I know that Outlook has a nice plug-in architecture which makes it seem like it might be possible to add a gpg plugin there. (I don't know much about it, but I installed the SpamBayes Outlook plugin at my work and that integrated seamlessly into the client.)

Critical mass is the key, and I can see a glimmer of hope that changing the definition of "trust" to make signed messages useful in blocking spam, combined with new, easier to use clients, could just make it all take off.

Everyone hates spam.

GnuPG for spamfighting?

I've been thinking lately how PGP/GnuPG could be used as a spam-prevention mechanism. I'm impressed with how easy Enigmail makes signing and checking signatures -- it seems like it should be usable by non-geeks.

If GPG-signing were to be used as a spamfighting tool, the meaning of "trust" (which always seemed vague to me anyway) would have to be changed. You would "trust" someone, even if you didn't know them personally, as long as it seems reasonable that person isn't going to send spam. If you receive signed spam that is somewhere in your web of trust, you mark the signers of that key as untrustworthy.

The lower threshold of "trust" would make more sense to a lot of non-technical users -- which is important, because everything I've read about signing keys on the net, is like don't mess around, this is serious business, only sign keys of people you've really met in person and that just means that, outside a small geek community, no one signs any keys.

I trust person X not to spam me ... hell, I'd sign a lot of keys of people from mailing lists and such that I'd probably never meet IRL. And that web of trust seems like it would actually be useful -- signing the keys of "real people" would be a matter of course, and if it were simple enough and gained critical mass, everyone would want to jump onboard.


It looks like only one person has downloaded my alternative iRATE implementation. That's too bad, but I guess it is rather specialized -- limited to people who are

  • on a platform where xmms runs
  • are comfortable installing perl modules from CPAN
  • run the official iRATE client (still necessary to download tunes), and
  • are not entirely satisfied with the official client, or at least curious to try an alternative.
Looks like that's just me.

I wanted to get my track-selection algorithm into the official client, of course, but it was a substantial change which would have been hard for me to write in an unfamiliar language. Combine that with a lukewarm reception for my proposal that made it seem like a patch would have a hard time getting accepted anyway, and I decided it was better to write something for myself in a language I was much more comfortable with.

I'm continuing to develop it and put the latest out on my website, but I'm not bothering with any official announcements.

Hanzi Quiz

I haven't touched this code in ages, but I have an idea how to improve it which I want to implement soon.

I wrote a utility program in perl (which you can find in the hanziquiz tarball) which takes pinyin with tone numbers (e.g. ni3 hao3) and converts it to pinyin with tone marks using utf-8 characters (something like nĭ hăo -- although that's with unicode numeric entities instead of raw utf-8). Now I'm thinking, if I move that conversion into the javascript of Hanzi Quiz itself, I can

  • make it easier to edit the test entries
  • have a fallback for browsers which can't display the accented characters (determined by a can you see this? up front)
Sounds pretty good, eh? The problem is the pinyin character ü (coded as a named entity here). That's hard to enter in text editors (except perhaps as an html entity ... oh that's hard too, just not impossible). In my perl conversion tool I use the character 'v', which isn't used in pinyin, to represent ü. I understand that's common, but perhaps not as common as 'u:' or 'uu'.

Should I code to expect the input to use 'v' (which is reasonable if I'm the one entering data), or should I try to handle other representations? What if I encounter html entities, or non-ASCII utf-8?

Eh, best start coding for the simplest ('v') case, and work from there. Yeah, I've talked myself into it just now.


I have a personal blog over at LJ. I had hoped to keep a blog on my own site, but I eventually decided that LJ was all set up for me, so why not just blog there?

The entries are few and far between now, but will probably become more frequent in the future.

Verizon Spyware Warning

My wife and I recently got a cellphone plan from Verizon. With our cellphones, they included a tutorial CD. I put it in my wife's Win2k box (it's Windows-only, of course) to see if there was anything worth seeing. It appeared to just be a gee-whiz flash presentation of the manual for people who can't read (I'm thinking there must be a lot of those these days!) Yawn.

At least that's what it appeared to be until I shut down the tutorial app. As soon as I clicked the close box, ZoneAlarm informed me that something named noptify.exe wanted to access the internet.

The CD installs noptify.exe as a hidden file in c:\winnt\temp, and it tries to contact the internet periodically as long as you have it installed. Verizon clearly goes to some length to deceive the user and cover their tracks.

Why would the largest U.S. wireless provider do something want to do something so ethically dubious? What sort of information are they gathering? Why would they want to risk their reputation by maliciously compromising their customers' computers?

I definitely want to make some noise about this one, but I haven't formed my plan of attack yet. I'm thinking of writing the FTC and/or my elected representatives and cc'ing Verizon customer support.

68 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!