www.sapphirepaw.org/blog

I have my head working on some sort of way to model gas consumption from a car. The basic question is: given a set of gears, what's the most economical way as measured in miles per gallon to accelerate? By and large, gas consumption is determined by engine RPM(*), which is tied through the transmission to velocity. Higher gears give lower RPM, and holding velocity constant, that translates directly to better gas mileage.

The question becomes: is it better to accelerate hard in a lower gear, then shifting up late, boosting consumption but packing it over a shorter time? Or is it better to shift as early as possible, spending more time accelerating more slowly in intermediate gears?

It's a surprisingly difficult problem. There's a nonlinear relationship between torque and RPM, along with certain limits on how much acceleration one can actually realize given the road condition. But once I find all the knobs to twist, it should provide hours of entertainment. ;-)

* The only statistically significant factor in my gas studies was driving for minimum average RPM, by traveling as much as sensible in neutral, especially on higher-speed roads. How "hard" the engine works, or how fast you drive (40 vs 60) don't really matter as long as it's the same gear in both cases. I am forced to conclude, as the gas pedal feedback suggests, that the line between working the engine lightly (engine braking) and heavily (acceleration) is a trivial amount of gas, and running to keep at the exact same speed is a fairly critical equilibrium.

It has come to my attention that Bash 3.0 has an option called 'pipefail'. This option, when engaged, changes a pipeline's exit status to be the status of the last failing command, instead of the last command. First things first: what if this failing is a cascade error? Wouldn't you like to know the exit status of the first command that failed, along with what it was? (Perhaps indicated as a position in a pipeline.)

pipefail is obviously a Bash-specific option, so why can't the full power of bash be leveraged in the first place to provide useful return codes? For instance, why can't the full array of exit codes be returned in some way, with vanilla $? remaining the last exit code of the pipe, for compatibility?

Say no to brain damage. Use ksh... or Perl where Perl is warranted. pipefail is the kind of bogus decision I would expect from PHP.

I have Internet again. Minimum SNR required for DSL: 6.0. Actual SNR: 26.0-30.0. Not bad for an address that, on my first call, was "not eligible" for DSL.

I've been having problems getting modern 2.6.16 kernels to boot. The SATA drive is apparently AWOL, as /dev/sdaX doesn't actually contain the root partition. (It hasn't moved to sdeX, hdaX, or hdeX either.) So of course the thing panics. You can't do anything to find out where the root partition actually is. You can't scroll back up the output because panics were meant to represent "Trust nothing", and so the scrollback buffer and keyboard driver have run away screaming. Like me.

Gentoo-sources seems to have some sort of patch that quietly conflicts with the NVidia binary drivers. (Lo, I am unclean, for I hath used a piece of NonFree(TM) Software.) It was improved by going to no-preemption, 100 HZ clock, and running without network, but vanilla 2.6.16 has yet to crash.

I still find the current Netfilter/iptables configuration Byzantine, complicated, and maybe chock full of forward references.

I reshuffled my drive beneath my feet, from [swap /:reiserfs /home:reiserfs netbsd-3] to [swap /boot:ext3 /:ext3 free]. Of course /home now lives on the / partition. Maybe it sounds like the "Marine" mentality that Edward Yourdon despises, but one puts in extra care rewriting partitions and copying data between them when one's last backup was almost a month ago.

Operating a house is like an extra part-time job. I haven't vacuumed or cleaned the bathroom since moving in. Or mowed the lawn. I'm getting clover in the front yard.

(funcall #'sleep (hours 16) cat) ; or so

Freakonomics by Steven D. Levitt and Stephen J. Dubner is an excellent read, and highly recommended. In the "stayed up until 3:30 AM reading it" kind of way.

Due to the personal involvement of a family friend, I'm going to give Alltel one more chance to screw up my Internet service, then I'm going to have to go with Roadrunner. There may be no worse company on the face of the planet than Alltel (currently spinning off and rebranding themselves as Windstream Communications).

I ran a chunk of wire from a box by the furnace to an outlet in the dining room, more or less smack in the middle above the furnace. 14-2-W/G runs out from the breaker box, across the basement, to the light by the laundry, back to the middle, over past the furnace, into the box in question, and over to another corner (diagonally opposite the breaker box) for a shoplight and pair of outlets on what must have been a workbench. The five feet between the furnace box and the actual outlet was some old 14-2 ungrounded BX wiring. It's like running a dedicated OC3 to every house, except it's terminated at the curb and switches to Cat3 to go inside the house.

My employers graciously let me come in on off hours to use the Internet. I was looking into the terms and conditions of HSBC's online savings account (currently with l33t 5.05% APY). If the bank is in any dispute, or any third party happens to make a claim to your account, in any jurisdiction, even if you aren't involved in the proceedings at all, the bank can reimburse itself for its trouble by taking funds out of your account. Of course they have to mail out a notice, but there's a time delay between mailing and receiving, during which one could be writing rubber checks. Not to mention that some companies are relatively slow about cashing checks, so they could start their life good but turn rubber before being cashed. Then the bank turns around and limits their liability on errors to the interest that would have been paid on the funds in question. Presumably, the funds themselves are Just Gone™.

Frankly, if someone's going to be in charge of a chunk of my money, they shouldn't be able to go around saying "Hey, it's your problem if we mess up." It separates the motivation to prevent errors from the capability to do so.

Feel .:: busy

Note: These pictures have not been selected for technical excellence or brilliant artistic composition. They are instead amateur-quality crops of even uglier frames, and one might count oneself blessed that I even bothered to sharpen them.

( Ready to go! )

Feel .:: blank

A lot of people (co-workers and customers alike) complained about their general lack of money at the gas station. Yet, behind their voice lies a quiet determination not to do anything about it. If someone values barhopping or lottery more than having the money, then that's where their money will go. They're not saying, "I'm willing to make that trade. No more bars, no more woman-chasing, I'm going to worry about getting richer."

I have to wonder if they even believed they could get richer if they tried. I never once thought about traveling abroad until I was in college, and someone asked me if I was going to. Although I didn't see it at the time, my way of thinking about the world was much like my parents': a destination to an exotic locale for a vacation would be somewhere like Lake Placid, at the other end of the state. Somewhere we could drive in a day or so.

Now that I've read Rich Dad, Poor Dad by Robert Kiyosaki, I'm looking at my financial state and thinking, "This isn't so bad, actually." I can get plenty richer than I am now, if my fiancée and I are willing to make those tradeoffs and play the game that way.

At the gas station, we would occasionally get an extra paycheck in a month, when we got paid the first, third, and fifth Fridays. As soon as that third check hit their hands, all the talk of "If I had money" from the others evaporated and more shortsighted purchases would happen.

Maybe it sounds trite or glib, but it truly is impossible to do (or finish) anything without the belief that it can be done, and that the only obstacle is finding the way.

I made a decision a while ago. When the paid time on this journal runs out, I'm going to revert to a free account and leave it at that. I've also quit developing on my LJ client. (Not that that was worth much. Before LJ quit posting stats, only about 40 people had ever tried it, and I might have 5 actual users.)

In real economic terms, I paid for LJ because it was completely ad-free. What little value I derive from the paid features is not enough to justify continuing to buy paid time, especially in the face of the Sponsored+ betrayal.

This is unrelated to recent events, but those events are the catalyst for making this post.

UPDATE: I realized last night that if I quit paying for LJ, I could spend the $25 on the Sharebuilder IRA management fee. A much, much better deal.

I've just spent 16 hours of work time researching, setting up, and generally banging my head against the wall with setting up Postfix 2.2.7 to filter only inbound mail through dspam.

• In a sufficiently complicated setup, it's not a good idea to have dspam share a uid table with anything. Due to forwarding aliases, you'll end up with either a uid for each alias, or remote usernames cluttering up the virtual mailbox table.
• It's probably not a good idea to filter outbound mail through dspam, so you'll want two IP addresses and two instances of Postfix to separate the inbound pipe (pointed to by MX records in DNS) and outbound pipe (pointed to by mail client configuration). The minimal collection of files to configure a Postfix instance is main.cf, master.cf, postfix-files, postfix-script, and post-install in the config directory, and a separate copy of the spool directory initialized by postfix -c your_cfg_dir check after your_cfg_dir is ready.
• Avoid letting mail to any dspam learning alias pass through content_filter. Trying to learn with dspam after the forwarded mail is processed again with dspam is guaranteed to break.

void echo ( string arg1 [, string ...] )

According to this function prototype in the PHP echo documentation it says you can do:

echo("string is: ", $string);

Except you can't. Hidden down in the paragraph that explains all about echo not really being a function (because you didn't really want a consistent language that knew what it was doing, did you?), it notes that the comma doesn't work if you used parentheses.

I am so sick of silly random restrictions and surprises in PHP....

Feel .:: irritated

The binary NVidia drivers for Linux, version 87.62, do not support the "voluntary kernel preemption" option. They seem to contain some sort of race condition that is fairly frequently triggered by heavy motion such as Xv, OpenGL first-person games, or mplayer's 2D X11 output driver. In my case, when the bug is triggered, the video card quits putting out signal, although the audio and CPU chug away for another 2-3 seconds before locking hard.

Stress tests have not been shown to be able to make it fail with the relevant kernel option set to "no forced preemption".

Feel .:: geeky

Firefox has a nice RSS icon, but at some point, there's no longer any way to get from the feed icon to the feed URL in one step. Left-click only offers "Add live bookmark", middle-click does nothing, and right-click brings up the "Customize toolbars" context menu.

So if, God forbid, I want to read feeds in a feed reader instead of using the clunky Live Bookmark interface, I'm forced through a completely manual set of hoops to do so. I have to create the Live Bookmark™, let Firefox fetch it, get its properties, copy the URL by hand, and only then can I bonk "Add Feed" and drop the URL in. And when it's all done, I have to crawl back in and delete the useless Live Bookmark.

All that just to whap the spacebar.

Whatever happened to the focus on being the best Web browser, instead of a Web browser, one-star feed reader, toaster, and Python interpreter?

I think my main problem with the Firefox UI for feed reading (and a core problem that seems to carry over into Fx RSS extensions) is that there's no list of all unread messages. How hard is it, really, to sort all feeds at once if you can already sort one? Even KDE (aKregator) and text mode (snownews) clients can get this right. What makes it so difficult for self-styled experts to design things like a usable feed reading mechanism, or usable open/save widgets? (GTK: That's you. Even the Windows 95 (ninety-five, which turns 11 years old this August!) common dialogs are better than that.)

Maybe the core problem is that when projects bring in UI designers, they shut out the world and listen to that one designer. That designer then retreats into the ivory tower and hands out proclamations which are then (possibly poorly) implemented. And when they return from the mountain with the next version of software, complaints and blame start piling up, only to be ignored. The designer is an expert, after all.

Design is an art, and maybe it's impossible to get right by listening to what users say. But it's equally impossible to get it right by handing it to a person that's decoupled from the users. The interface is about the users, and if formal user tests are prohibitively expensive, then the next best thing is user feedback. That doesn't work when it's deflected to the bit bucket.

Writing code on the average open source project is a lot like running a startup or a small business. The developer has to be able to do everything, because there aren't enough people working on the project to specialize. System analysis, architectural design, user interface design, marketing (even if it's not glossy brochures), user and possibly developer documentation, end-user tech support, patch management, code review, testing, maintenance, and the 10% of the work that remains is for the actual implementation.

Very few people are good at all this. There's a lot of attitude in the open-source community that the developers shouldn't have to do anything but write code, and that the users should burden themselves with learning and adhering to the project policies for bug reporting. Even better, users should burden themselves with submitting the patches, but as open-source is gaining more users, reality has firmly denied that dream.

Open source developers need to realize that handing out source instead of a binary doesn't change the fundamental economics of development. To be a success, one either needs to balance all the parts of running a business, or be such a useful project that enough different types of people join to complement the original developer's weaknesses. Maybe writing code is sexy, but it's just one stop on the road to having users, and it's those users that can really make a piece of software shine.

In a lot of ways, PHP strikes me as a halfhearted language.

Is it case insensitive? I ran a batch of tests today, and discovered the answer is yes and no. Variables, associative array keys, and object properties (dynamic and static) are case-sensitive. Function calls, methods, and class names are case-insensitive. But for what? What does this case-insensitivity gain? It can provoke weird bugs, it costs in time and space, and for all that, it offers zero benefit. (It costs in space because now, the reflection extension requires the storage of both the lowercased classname that ZE actually uses, and the original-case classname for displaying from Reflection.)

Is it a Web language? No. There are no header-handling facilities whatsoever beyond whatever anyone could do with plain old CGI. When I wanted to make an executable download and run on Internet Explorer, it was up to me to read the HTTP specification, search the Web for MIME info (and, happily, I stumbled across IE bug workarounds while doing so), and code up a string of header() calls by hand. What if I want to make a PHP page cacheable? Back to the HTTP spec and header(), to put out appropriate ETag, Expires, Cache-Control, and Last-Modified headers. By hand.

Is it consistent? No. While approaching things from the correct angle (strstr() mimics C, str_replace mimics preg_replace(), so of course they take arguments in a different order) can make a little bit of sense, those gains in sense don't do anything for the other nonsensical parts of the language. Incidentally, if they're "PCRE Functions", why do they begin with "preg"? That was a cause of severe headache once upon a time. More nonsense is evident in the PHP "callback" type. It seemed very weird when I first read about it, but I got used to it, and it worked fine for most situations where one needs to shoehorn a method of some sort into a context that expects a function. Then I discovered it doesn't work for function_exists(). There's a separate method_exists() call for that!

Is that inconsistency an isolated wart? No. Certain language constructs are built so that they can look, smell, and taste like functions, until a hapless programmer tries to do something functional with it. For instance, $message = "big long complicated thing"; die($message); will provoke a parse error, because die can't handle having a variable. Similarly, func_get_args() can't be used in function-call context for reasons that I have yet to discover. Another interesting parse error is what happens if one naïvely expects to access some static class dynamically. That is, if a variable $c holds the desired class name "MyClass", $c::$x can't be used to access MyClass::$x. On the other side of the T_PAAMAYIM_NEKUDOTAYIM (that's annoying PHP developer speak for "::") pretty much anything goes. Even PHP's variable-variable mechanism works, so if $v contains "x", MyClass::$$v is equivalent to MyClass::$x.

Is there more? Of course there is. PHP can't decide whether it wants me to trust a default value, or if it should whine about it. If I want to pass a value from $_POST, or null if it didn't exist, into a function, simply writing a_function($_POST['value']) will provoke a notice that $_POST['value'] was unset, if that was the case. It doesn't matter that I don't do anything with the variable before a_function checks whether the passed value is null. Throwing useless errors only makes people turn off error_reporting, stripping away a valuable debugging tool if some distributed code such as Pixelpost 1.5beta1 doesn't quite work. (Which is a subject I have incoherently ranted about in the past.)

That has to be all, right? Wrong. PHP provides a set of functions that work on an "internal array pointer", such as next(), key(), current(), and friends. The function that returns that array pointer to the beginning of the function is named reset(), because rewind() does a similar operation to the file pointer of a file handle. Virtually all of the functions that deal specifically with a file handle begin with f: fopen, fclose, fgets, and even non-libc type functions like fputcsv. But rewind, continuing the libc tradition, is not frewind, so rather than improving on those that came before, PHP kept rewind as it was, and invented reset(). Fast-forward to PHP 5 and the Standard PHP Library: when implementing the Iterator interface, the method that is to bring the array pointer back to the beginning is rewind. So of course I try to call rewind($array) by accident in that method.

Over on the administrative side of things, PHP INI directives that are marked as "PHP_INI_SYSTEM" can actually be set per-directory from Apache, by placing the relevant setting inside a <Directory> container in the Apache httpd.conf. System, in this context, does not actually mean global, although the existing documentation implies that is the case. All it really means is that it can only be changed from the system configuration files, not in the per-directory configuration. (Although, since the system config can be coaxed to be per-directory and works just fine, why does the distinction exist?)

I'm not even digging into the bizarre things that PHP does when presented with pathological cases like unset(null) (Unexpected ')', expecting T_PAAMAYIM_NEKUDOTAYIM - expecting 'null' to be a class name!). Considering those shouldn't work in the first place, that wouldn't be fair. Still, the language is the proverbial box of chocolates. I have more little testcases for PHP than I ever had for Perl, and that's only since I started saving the scripts because it became clear I might need to reference them again. There are also the unsolved mysteries, such as why reading 22 MB out of a pipe will overflow a 64 MB memory_limit and kill the script. Even double-buffered, there shouldn't be more than 44 MB there, and I can't see what another 20 MB could possibly be in use for.

I'm not digging into the weirdnesses the future will bring, such as the removal of magic_quotes without the addition of, say, taint mode. The PHP developers refuse to add taint mode because they are thinking inside the box of magic_quotes; their argument is that taint mode would require knowing too much about the context of the data's intended use in order to taint it properly. Perl, on the other hand, relies on the programmer to tell it the context with a regular expression: only pieces you pick out of the regex match are marked as untainted. Of course this leaves the door open to using /(.*)/ as a pattern and bypassing taint mode, but it's clearly better than having no tainting at all. Another future weirdness is the continued lack of named parameters, forcing everyone to continue to pass an associative array to emulate them in userland.

Feel .:: irritated

Kelly Martin makes the case that the time has come to ditch email, and in a discussion of the possible alternatives, says:

I enjoy the thought of a spammer needing a giant Bewolf cluster ranked rather high up in the Top 500 list of supercomputers to send one piece of spam to ten million people.

Via Planet Ruby, this post in the Ruby on Rails blog caught my attention. "How has Rails made something possible/ easier/more productive?"

I think the question is not, "how well are we doing?" but "how could we do this better?" Has Ruby on Rails made anything more difficult than another language or framework? Is it worthwhile to try to improve that experience?

Fundamentally, companies and projects need to listen to all their users, not just the fans. There is more to the pie chart than a single slice.

Modern versions of sudo allow for the '-e' flag or the 'sudoedit' alias, to enable people to edit files without the possibility of gaining a root shell. In sudoedit mode, sudo makes a temporary copy of a file to be edited, sets the ownership to the invoking user, and runs the editor on that file with the permissions of the user. When the editor finishes, sudo copies the fresh temporary file back to the old location.

If sudoedit with no arguments lets one modify arbitrary files, then what happens for sudoedit /etc/sudoers? Well, it works just fine, despite warnings in the comments that one should always use visudo. This means that, given unfettered sudoedit powers or even access to only /etc/, the grantees can grant themselves more sudo powers.

The obvious solution to this is to disable allowing sudoedit to edit /etc/sudoers. This can be done with command permissions sudoedit, !sudoedit /etc/sudoers, but even that's not particularly safe. Give a user permission to access rc.local or equivalent, and they have the power to do rootly things when the machine boots. cp /bin/sh ~user/a.out && chmod 4700 ~user/a.out for instance.

What's really at issue here is that /etc/ is, conceptually, a mess. It has code, it has mundane data, and it has security policy, all mushed together in the same tree. There's no effective way to grant access to a individual rooms if they all share one door, except by (expensive) vigilance.

I've been poking and kicking at Apache and mathopd lately. Executive summary:

• Athlon64, even in 32-bit mode, is way faster than AthlonXP.
• Apache is not slow; in fact it's O(1) in the number of simultaneous connections, thanks to Linux 2.6's O(1) process scheduler.
• Apache is not a memory hog; it just looks like one in top or ps.

Feel .:: geeky

When I'm learning a new language, typically I think a lot about language design. This is one of those cases. ( Read more... )

Feel .:: geeky