Older blog entries for elanthis (starting at number 383)

Tag Renewal

License plate tag renewal fee: $54

Late license plate tag renewal fee: $108

Ticket for having expired tags on my plate in East Lansing: $130

Total savings if I hadn’t been a moron and forgotten to renew my tags: $184

Ability to set reminders in Evolution for next year’s renewal date: priceless.

Syndicated 2008-07-03 16:55:55 from Sean Middleditch

Motherboard Hell

I’ve been meaning to upgrade to a newer and FOSS-supported video card. Since I like nice, quiet, low-power systems, that requires an integrated graphics chip. My current motherboard makes use of an NVIDIA 6150, but I really would like either an AMD 780G or Intel X4500 (when they’re out).

Since I had a birthday recently and my parents were bugging me to ask them for something, I decided to ask for a 780G motherboard. I then went and bought DDR2 RAM and a Phenom X4, as my old Athlon X2 is a socket 939 model.

The new motherboard unfortunately was a huge problem. It would hang randomly on boot, gave Linux various errors, and caused some instability. I figured it could also be the CPU or RAM, but it’s really hard to find out when you don’t have anything else to swap in. I had my parents return the motherboard and a bought a new one, which came recommended from Phoronix.

That one wouldn’t even power on.

At this point, I’m pretty much sick of pulling my computer apart and putting it back together over and over. If the replacement motherboard doesn’t work (or it turns out to the CPU or RAM) then I’m just going to send it all back and say “screw it.” Maybe I’ll try again when the Intel GMA X4500 motherboard are out, maybe I’ll just get a cheap R600-based PCI-E card and stick it in my current machine, or maybe I’ll just live with the proprietary-driver necessary for my current graphic chips. (Yes, necessary - neither of the Open Source drivers nor the VESA driver are capable of giving me a usable desktop on my monitor - I either get stuck with a tiny-ass resolution, a missing mouse cursor, or a picture that’s offset by about 50% vertically.)

Putting computers together can be kind of fun, but it’s not at all fun when putting new ones together requires you to pull apart your one and only working computer, and hoping nothing goes wrong and damages your existing working parts in the process. And I really don’t feel like having to order a new case (which costs almost as much as a CPU these days - WTF?) and hard disk just to be able to try over and over to build a new machine until Newegg manages to ship me working parts. :/

Syndicated 2008-06-25 03:49:04 from Sean Middleditch

Fedora Firefox Fsync Fix

The sqlite/fsync behavior of Firefox that’s been so heavily publicized lately is biting me in the ass, and hard. When Firefox is open, my machine frequently starts churning the disk, and any application which needs to write to the disk grinds to a halt. The second these 15-25 second pauses are done another one usually starts. It is quite literally driving me out of my mind in frustration.

For whatever reason, Fedora does not seem interested in fixing the issue. Despite Mozilla’s recommendation to apply a patch to fix the issue, Fedora will not do so (according to the bug report). I don’t know if 3.0 RC2 fixes the bug upstream, but even if it does, there are no Firefox updates for Fedora. I’m pretty much on my own here.

I tried to use a simple fsync wrapper with LD_PRELOAD, but I could not for the life of me get it to work. I don’t know why, as logically it should work just peachy. The library gets pre-loaded, but the wrapper functions just never get called. I’ve done this sort of thing before I was fairly confident that I was doing everything right, but the fact that it didn’t work clearly indicates I overlooked something.

My current “hack” is rather extreme, but it’s doing the job wonderfully. Given that I have an excess of RAM in this machine (2GB is more than I need… and I’m adding more in a week or two), I decided to create a tmpfs filesystem with a limit of 500MB, backed up my .mozilla directory, put a copy on the tmpfs filesystem, and symlinked ~/.mozilla to that. Since fsync is now essentially a no-op, I no longer get greats amount of disk churn.

It’s worth noting that some of the other programs i use probably contributed to the excessive churn. Pidgin writes to disk way too often (there are bugs open upstream on this), and for whatever reason it fsyncs even on the unimportant ones, like buddy icon caches. Evolution caches mail on the disk. Vim is constantly writing its swap file and fsyncing left and right. It probably shouldn’t be too much of a surprise that a ton of processes are building up data to be written out, fsyncing, and while blocked more data is built up, just to be followed by another fsync.

Particularly frustrating though is that even when I’m not actively using Firefox — it’s open, but on another workspace, not being interacted with, not even with sites using JavaScript or automatic page refreshes — it still manages to make my disk churn. Likewise, Pidgin seems to be writing files out at various points in time even though nobody is IMing me, nobody’s status is changing, my preferences aren’t changing, etc.

In any event, the tmpfs thing works. I just hope I remember to copy the data back to my real ~/.mozilla before I shut down the computer, because I actually do like to keep my history. I just want it to work like Firefox 2 where keeping my history did not require sacrificing my I/O throughput and sending my disk drive to an early grave.

Fedora Firefox Fsync Fix… Four F’s? Freakin’ Fantastic!

Syndicated 2008-06-14 01:00:19 from Sean Middleditch

Design of PHP

Having worked with PHP professionally for some 9 years now, I’ve slowly acquired a very dismal view of the language. Don’t get me wrong - it works, it gets the job done, and in a lot of cases there simply isn’t a sensible alternative. But let’s be honest with ourselves: PHP sucks, and it could have been a far better language.

The shortest summary of my complaints against PHP are that there was absolutely no real design effort put out before the language was written. Or before any major version release after the first. Or in the next version release, PHP 6.

PHP has a large number of well-known “oopses” built up over the years. Auto globals and magic quoting are perhaps two of the best known. Auto globals might seem like a good idea at first, but even a little bit of thought would have shown how problematic it would turn out to be. Magic quoting is another idea that might seem good if given only a few seconds thought, but if one sits down and really thinks about the problem — developers not quoting the strings they’re concatenating together to form SQL queries — it’s not hard to come up with a handful of better solutions.

Aside from the glaring mistakes, PHP also suffers from what I call the Misplaced Generality Tendency. PHP, like many other languages, are designed with a very general-purpose syntax and library despite the fact that PHP was written for one purpose: web applications. Web applications for the most part do two things very frequently (database queries and HTML output) and a lot of other things very infrequently. It would have made a lot more sense to specialize PHP towards DB queries and SQL as well as easy and safe HTML output rather than designing this general purpose C/Java/Perl like language that doesn’t really do anything better than those languages other than having an Apache module (which time has shown us is a bad idea for security reasons - hello fastcgi and suexec) and being easily embeddable in HTML (which most of us don’t even do anymore - we use domain-languages like Smarty or PHP Sugar for output).

It would be nice to think that PHP is slowly getting better, but that does not appear to be the case. When MDB2 was released as the replacement for PEAR::DB, we found that using SQL was just as much of a pain in the ass and easy to get wrong as before. You have to jump through extra hoops to get the placeholder syntax (which, in turn, uses stored procedures even for one-off queries) with MDB2 instead of it being the default, recommended way of doing things. You’re still forced to treat all SQL as just a regular string — same as all that dangerous user input — instead of treating SQL as a first-class citizen of the language. Imagine for a moment that you could write something like:

$result = $dbh->query({{ SELECT column FROM table WHERE id=$_REQUEST['id'] }});

The {{ }} syntax is for illustration only: there are a number of alternatives that might be more aesthetically pleasing. Now, imagine that PHP not only recognized the SQL expression, but also knew to automatically quote the $_REQUEST['id'] variable appropriately. Sometimes you do need to build up your SQL queries like they were strings - it’s rare, but it happens. The syntax above makes it trivial to support this.

$conditions = {{ }};
if ($_REQUEST['name']) $conditions .= {{ WHERE name={$_REQUEST['name']} }};
$result = $dbh->query({{ SELECT column FROM table $conditions }});

When a SQL value is inserted into or concatenated with another SQL value, the result is just what you’d expect.

The query method on the $dbh object would reject any input that isn’t a SQL value. It would not automatically coerce a string into a SQL value or anything like that.

In those instances where you really do want to take user input and turn it into a query (for software like PHPMyAdmin), you can provide a simple method to convert a string into a SQL value. Make it sound scary if you want, or just document it well if you trust your users to read (I don’t).

$sql = unsafe_string_to_sql($user_input);

Life would be so much easier if PHP actually decided to support SQL in the language, like any language that works 90% with SQL should.

HTML output with PHP isn’t much better. Tools like echo or print are almost as dangerous as the existing SQL libraries in PHP. The problem lies with XSS attacks and malicious content injection attacks. Simply spitting user data out to the page allows users to inject JavaScript, Flash, ActiveX, Silverlight, or other potentially harmful data into a page. If the site stores requests from users and then displays that data to other users, you’ve got yourself a big problem. Almost as big of a problem as if you just let users inject raw SQL into your database queries.

Sure, you can make your output safe using htmlentities() or htmlspecialchars(), but that’s kind of a pain — just as much of a pain as having to add $dbh->quote() all over the place in your SQL string concatenations. At least MDB2 allows you to use placeholders after enabling them; PHP has no such feature for output.

Of course, most of us use a templating engine anyway. It’s really not the core application’s job to be spitting out HTML. Really, there’s no even any good reason for the embedding syntax (the stuff) in PHP. It may have made sense back when PHP was just a hopped up server-side includes mechanism, but in the days of PHP6 (or even PHP4) it’s practically useless.

Several design flaws are illustrated by the templating needs among PHP developers. First is the fact that PHP is not at all intended to be a templating engine and yet still tries to pretend that it is one. Second is the fact that PHP is not intended to be a templating engine at all. Think about it: why is Smarty or PHP Sugar necessary? Why not just include another PHP file?

Well, for starts, there is no sandboxing mechanism in PHP. There’s no way to include a file and guarantee that that file can’t access dangerous library routines or modify application data. The PHP syntax is also relatively unfriendly to Web design professionals — PHP is focused on generalism and the C/Java/Perl syntax instead of being focused on its core domain, remember? Finally, simply including PHP scripts as your templates would provide you with a separation of core business logic and presentation but would not grant you any other niceties such as easier output of safe content.

Unfortunately, just as MDB2 doesn’t do nearly enough to offset PHP’s non-existent SQL integration, projects like the Smarty engine (which by all appearances is the semi-official PHP templating solution) don’t do nearly enough to offset the numerous design flaws PHP has regarding its HTML output facilities.

For example, even though Smarty make function calls look more like HTML tags (good for Web designers), it also managed to choose a code delimiter and conflicts with JavaScript and CSS; expose pointless internal complexities on the user like forcing them to know when to use -> and when to use . to access value properties; makes it easier to unsafely output user data than to safely output user data by requiring explicit escaping; and focusing on generalism instead of offering as many tools that are frequently needed by designers as possible. In most ways, Smarty seems to have been designed the same way as PHP — which is to say it wasn’t really “designed” at all.

PHP could alleviate many of these problems. It could have used a syntax more familiar to Web developers (which might include trying to look more like JavaScript than Perl). It could have offered a sandboxing facility. It could allow an include mechanism that enabled the embedding syntax while leaving it disabled by default for regular files. It could make sure that echo statements or statements automatically HTML escape their output by default and make outputting raw data require the extra steps instead.

Web developers would be best supported by a language actually designed for Web development, which is not the same as a language that was haphazardly slapped together with the intent of using it for Web development.

In general, I believe that it’s often better to learn and use an assortment of domain-specific languages rather than trying to make one language fit all needs. It’s often a lot easier to learn a small language specific to a single problem domain with syntax and functionality targeted exactly at what a developer is trying to accomplish rather than trying to learn large and complicated tricks to get a general purpose language to do what is needed. I often hear the mantra that developers love being able to do all their work in one language — such as being able to code both the server logic and the client behavior in C# using ASP.NET and Silverlight — but I contend that developers ask for this only because they have already been forced to build up a large assortment of C#-specific tricks and hacks to accomplish oft-repeated goals and that the alternatives to Silverlight are themselves general-purpose languages shoe-horned into a relatively simple problem domain (UI behavior).

It’s easy to see that this philosophy has been in effect amongst true computer scientists for at least 30 years just by looking at one of the core UNIX design principles: many small tools that each do a specific job and do it very well. Even in terms of language, UNIX has plenty of examples: awk, sed, tr, regular expressions, C, shell script, yacc/lex, and so on. It may take some time for someone already familiar with C to learn the awk syntax, but in for very specific yet frequently occurring problem domains it will take a programmer less time to learn awk and then write an awk script than to try to develop the equivalent logic in C. Tools like Perl may all but make languages like awk obsolete (a design goal of Perl if I recall) but there are still plenty of other problem domains with Perl barely does better than C.

Unfortunately for all of us working with PHP professionally, the only thing PHP has going for it that any other languages don’t is that PHP comes as standard in pretty much every web hosting provider service out there. After that convenience is granted, we have to start struggling in order to overcome PHP’s misdesigns and do our job: writing maintainable, secure, stable, efficient web applications. PHP is a toolbox full of interesting and useful tools — just not the ones we need to use most often.

Syndicated 2008-05-29 01:23:52 from Sean Middleditch

New LARP Weapons

Spent some hours making these. I hope they’re actually legal. :/ The halberd (looks far more like a german poleax, oops) is constructed with 1″ diameter rattan, a styrofoam kickboard, the usual tan pipe insulation, some thinner dark tan (not black) pipe insulation I found, and strapping tape.

The halberd’s head is a bit bigger than I intended. I cut the styrofoam without taking into consideration the width of the padding (I used the light tan stuff for the blade’s edge, and the head spike and butt spike), so the blade came out a bit more gargantuan than I wanted it.

The dark tan padding used on the haft kinda has me worried - it’s not the rubbery black stuff that breaks down uber quick - it’s the exact same material as the light tan padding - but it’s only about 5/8ths as thick. I actually like that fact, but it may not be up to the standards of the game I’m heading to this weekend. Guess I’ll have to find out. It seems to hold up all right and is just about as cushy as the thicker stuff, but I imagine I’ll have to repad it sooner. Granted, the light tan stuff can last well over a year if you aren’t hitting like a retard and store your weapons somewhere acceptable.

The sword is a little atypical in construction too. The hilt is attached a little differently than most, as it’s a single length of padding with a hole cut through the middle edge-wise, and the PVC slide through that. It’s then secured with a healthy amount of strapping tape, similar to how all the bits are attached on the halberd. The blade was then covered completely in the dark tan padding, and then another strip of the dark tan was cut in half and doubled up on the blade edges. This gives the sword a slightly nice shape, although it’s giant and bloated compared to a real sword. The thrusting tip then has some extra light tan padding to give it a slight taper and extra cushion. The pommel is the regular light tan padding construction, albeit attached with strapping tape instead of just duct tape.

I have complete confidence that the sword is safe. The blade edges are actually even cushier than normal boffer swords since the dark tan stuff doubled up is a bit thicker than the light tan padding.

Syndicated 2008-04-11 18:12:42 from Sean Middleditch

OpenJDK / IcedTea Web Plugin

I’ve been completely unable to get most of the Java plugins I need for work to operate using the OpenJDK / IcedTea plugin that both Ubuntu and Fedora shipped. Looking into things, it appears that they’re using a modified version of the GCJ plugin which has always been pretty behind the curve when it comes to actually working.

Anyone know why the official Java plugin isn’t released with OpenJDK, or if it is, why IcedTea is sticking with the incomplete GCJ plugin?

On a side note, why does OpenOffice.org on Fedora 9 require java-1.5.0-gcj instead of using java-1.6.0-openjdk? It seems a bit goofy to have two JRE’s installed.

Syndicated 2008-04-03 16:08:42 from Sean Middleditch

OpenID Not The Best Bet

So, I’ve tried toying around with OpenID a bit, and I’ve come back feeling a little unimpressed.

There are two problems. First, it is still a super pain in the ass to setup an OpenID server. None of the servers I could find were installable with a simple tarball unpack and config script - they all required source modifications and even then didn’t really work. There are toolkits for building OpenID servers, but no ready-to-run servers.

The biggest problem though is just the user-experience as a whole. Having to type in anything at all is still kind of clunky. I want single sign-on - if I am online, any site I go to should be able to verify I am the entity I was last time (with the ability to easily allow/deny sites from doing so). I shouldn’t need to type anything in. The amount of information available to the system should be more than enough for any site, be it a simple blog comment form, a forum, or an online store.

I’m all for having a server to centralize this, but I don’t think the technology should be built around users interacting with this server. The server should be a storage medium at most, not the actual UI. Instead, I am imagining a browser extension (which should be possible for Gecko, IE, WebKit, and Opera) that exposes a new JavaScript object, something like window.AuthService. This object allows the site to query information about the current user, including name, email, contact information, etc. It will also be able to retrieve a user ID (which would probably be an email address, or something else guaranteed to be unique per-user) as well as a site token. This token would be a completely unique and cryptographically strong random identifier that is associated with the user ID and the site domain. In particular, each user/site combo gets a different token.

So, I connect to google.com, and it wants to know who I am. It queries window.AuthService.userId and window.AuthService.siteToken and gets ’sean@mojodo’ and ‘F583AC9…4AC’ back. It then uses these to log the user in, or create a new account (which in many cases could be completely silent).

The first time a site attempts to access the AuthService object, the browser can display a popup (or one of those notice bars that are becoming popular) informing the user that the site wishes to identify him, and allow him to accept the authorization (possibly selecting between multiple profiles), permanently accept it, deny it, or select the access level (id and token only, id token and contact info, etc.).

The central server comes into play by allowing the browser to configure such a server (which could easily just be an LDAP server) to grab identifies from. Browsers set up in public terminals could be configured to ask for the server login information when the user first accepts an AuthService request (and not store this information past the end of the browser session). This allows users to keep their authentication information somewhere central, but keeps the UI solely in the browser allowing for a far better user experience.

Obviously a lot of details need to be worked out, including the exact interface (would it be better to use HTTP headers rather than or in addition to JavaScript?), the UI needs to be nailed down, etc.

I’ve considered writing a Mozilla extension for this (as well as extensions for WHAT-WG Connection class and Server-Sent DOM Events), but writing extensions for Mozilla is such a byzantine process and the documentation on how one might register new objects in windows (and do so securely - the docs just say it’s insecure if not done right, warning you not to do it, which is fucking useless compared to just explaining how to do it correctly and securely) that I haven’t been able to get anywhere on any of those ideas.

In the end though, I think OpenID is pretty much dead technology. At most it might become very slightly popular with blogs for posting comments, but it’s usefulness pretty much ends there. The UI sucks and the ease of user control and information handling is too lacking.

Syndicated 2008-02-14 19:11:50 from Sean Middleditch

Mojodo Inc.

I finally got my hands on the domain I’ve been drooling over for over a year now, and am currently in the process of converting AwesomePlay Productions, Inc. into Mojodo Inc.

I’ve kind of hated the name awesomeplay for a long time. I came up with it back when I was, oh, 11. I think it was a direct rip of Interplay Productions, my favorite computer game company at the time (they published Dungeon Master II and Stonekeep). The name is pretty lame, dated, and unprofessional. Mojodo on the other hand is totally Web 2.0, which is also kind of lame in its own way, but what else is expected when every other reasonably intelligent domain name is taken. :)

The actual company site, once I get it developed, will be hosted at mojodoinc.com, and a new Service (oh crap) will be hosted at mojodo.com once I have the time to invest in that.

In slightly unrelated news, it’s kind of surreal that I’ve found articles written about PHP-Sugar already. Hopefully soon the new domain will be the top hit for Google searches, and the online reference manual should be ready in a week or so. 1.0 isn’t far away.

Syndicated 2008-02-14 07:29:03 from Sean Middleditch

PHP-Sugar 0.73 Bugfix Release

Several bugs were found in the 0.72 release of PHP-Sugar, so I’ve released 0.73 with fixes.

The two main fixes are a correction to the Sugar::isCached() method to always return false in debug mode and fixes to avoid warnings and errors in E_STRICT mode.

I also fixed up some of the tests to work properly again, and added a new test for comments.

Syndicated 2008-02-12 06:00:19 from Sean Middleditch

PHP-Sugar 0.72 and New Website

Earlier today I registered php-sugar.net, and installed the site code from sourcemud.org. The site code isn’t quite complete (the bug tracker, for example, doesn’t let me edit bug statuses yet, nor search for closed bugs), but otherwise I’ve got a complete project hosting solution ready. Things are even better when using git, since I have a very functional git browser built in to the sourcemud.org code; too bad php-sugar uses Subversion.

Even more interesting than the new site, however, is the release of PHP-Sugar 0.72. This release contains the last of the major feature additions before I’m ready to move towards a 1.0 release. The new feature is that HTML caches now store the list of all template files used to create the cache, and these files are checked on cache load to see if the cache is out-dated.

There are certainly some more cleanups and very minor feature additions I’d like to do (mostly new functions for template authors), but php-sugar is for the most part feature complete at this point. Hopefully I can get a 1.0 release out in the next month or two.

Syndicated 2008-02-09 06:23:03 from Sean Middleditch

374 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!